Messages in this thread | | | Date | Fri, 25 Jun 1999 15:32:40 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
Date: Fri, 25 Jun 1999 12:14:38 -0400 (EDT) From: Alexander Viro <viro@math.psu.edu>
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/
| |