Date:	Fri, 25 Jun 1999 12:14:38 -0400 (EDT)
From:	Alexander Viro <viro@math.psu.edu>
To:	torvalds@transmeta.com
Subject: [RFC] File flags handling - proposal for API.

	With all talks about mixed directory/symlink objects, etc. we
*will* need a decent way to work with such attributes. I dearly hope that
it will not be done via weird ioctl() as it's currently done for ext2
flags (for one thing because the object we are operating with may not be
openable - e.g. symlink).
	Notice that there is a difference between the attributes affecting
the VFS behaviour (append-only, etc.) and ones the VFS (or even kernel) 
doesn't care of (no-dump, etc.). For the latter we probably want to pass
the raw attributes to the fs and let it figure out what it wants. For the
former the common representation is needed. So we want a way to deal with
raw and generic attributes.
	I think that the right way here is to add 6 (ouch) syscalls:
{l,f,}chflags() for setting those attributes and {l,f,}new_stat() for
reading them. The reason for latter 3 is simple - potential races.
	Differences between lfoo, ffoo and foo are the same as in cases of
chmod, chown, etc.
	int chflags(char *name, int is_raw, int flags) would set the
attributes - raw if the second argument is true, generic ones if it is
false.
	int new_stat(char *name, struct new_stat * buf) would fill the
buf with extended variant of struct stat - additional fields being generic
and raw attributes. This will be redundant, indeed - that would allow
fs-specific programs to deal with raw attributes in redundant way, but at
the same time spare normal programs from the need to know the representation
of generic attributes on particular filesystems.
	Modulo the distinction between raw and generic attributes this was
tested on 4.4BSD - it works fine there.
	I am ready to write the thing - I have the patch mostly done. It's
non-intrusive, in sense that any filesystem that doesn't want to know
about those animals will require no changes. If you are OK with the
proposed API I'll do it. Comments?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/