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.
The interface for filesystem-specific attributes needs to be carefully
thought out. Right now, how is a an application supposed to figure out
which filesystem a particular file is being stored as? The only
solution is to stat the file, and then grovel through /etc/mtab stating
each of the devices in /etc/mtab and matching against the device number
found in the stat information.
This is not a new problem; ext2's chattr simply blindly tries an
ext2-specific ioctl, and assumes that some other if a file belongs to
another filesystem, the ioctl will either not exist and EINVAL will get
returned, or the ioctl will do something vaguely rational on that
alternate system.
But if the assumption is that many filesystems will be supporting this
interface, I would change the "int is_raw" parameter to be "int
attr_namespace", where 0 is the generic attribute name space, and other
filesystems can support attributes in one or more assigned attribute
name spaces. If a filesystem doesn't support a particular attribute
namespace, it can simply return an error.
So I would suggest the following: (with similar function signatures for
the 'l' and 'f' variants):
chflags(char *name, int attr_namespace, int *new_flags, int *curr_flags)
If new_flags is non-NULL, then it is a pointer to the new flags which
should be assigned to the file. If curr_flags is non-NULL, then it is a
pointer to the flags *after* the chflags operation. This makes it easy
for an application to check whether or not the filesystem refused to set
a particular flag (for example, if it doesn't support that particular
flag).
- Ted
-
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/