[lkml]   [1999]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] File flags handling - proposal for API.
       Date: 	Fri, 25 Jun 1999 12:14:38 -0400 (EDT)
    From: Alexander Viro <>

    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

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.019 / U:9.704 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site