FAT, NTFS, CIFS and DOS attributes

Anton Altaparmakov aia21 at cam.ac.uk
Tue Jan 4 10:34:25 GMT 2005


On Mon, 2005-01-03 at 14:24 -0800, H. Peter Anvin wrote:
> I recently posted to LKML a patch to get or set DOS attribute flags for 
> fatfs.  That patch used ioctl().  It was suggested that a better way 
> would be using xattrs, although the xattr mechanism seems clumsy to me, 
> and has namespace issues.
> 
> I also think it would be good to have a unified interface for FAT, NTFS 
> and CIFS for these attributes.
> 
> I noticed that CIFS has a placeholder "user.DosAttrib" in cifs/xattr.c, 
> although it doesn't seem to be implemented.
> 
> Questions:
> 
> a) is xattr the right thing?  It seems to be a fairly complex and 
> ill-thought-out mechanism all along, especially the whole namespace 
> business (what is a system attribute to one filesystem is a user 
> attribute to another, for example.)
> 
> b) if xattr is the right thing, shouldn't this be in the system 
> namespace rather than the user namespace?
> 
> c) What should the representation be?  Binary byte?  String containing a 
> subset of "rhsvda67" (barf)?

Definitely not c!

In NTFS, the "dos attribute flags" are part of the system information
attribute which is an entity in its own right, totally separate from
extended attributes (and named streams for that matter).  So if I were
to be thinking in an NTFS-only world I would be inclined to use an
ioctl() to access/modify them (i.e. not b either).  So if you implement
an ioctl() for vfat I will probably be able to provide the same in NTFS
with almost zero effort (we already have the code to read and write the
attribute flags in the kernel ntfs driver, we just do not provide an
interface for it).

But please note that it would be best if you could use 32-bits for the
flags.  At the very least 16-bits though as on NTFS there are currently
in use 16-bits in the standard information but the field is u32 sized on
disk (little endian) and two of the higher bits are in use in the file
name attribute as well and I would not be surprised if more bits get
used in future NTFS releases.  Tridge already gave you a list of all the
Samba dos attributes so here is the full list for NTFS (note they are
100% compatible to the Samba ones and also note in NTFS we always keep
the flags in little endian and just define all the constants to be
little endian as well - makes life much easier):

/*
 * File attribute flags (32-bit).
 */
enum {
        /*
         * The following flags are only present in the
STANDARD_INFORMATION
         * attribute (in the field file_attributes).
         */
        FILE_ATTR_READONLY              = const_cpu_to_le32(0x00000001),
        FILE_ATTR_HIDDEN                = const_cpu_to_le32(0x00000002),
        FILE_ATTR_SYSTEM                = const_cpu_to_le32(0x00000004),
        /* Old DOS volid. Unused in NT. = const_cpu_to_le32(0x00000008),
*/
                                                                                
        FILE_ATTR_DIRECTORY             = const_cpu_to_le32(0x00000010),
        /* Note, FILE_ATTR_DIRECTORY is not considered valid in NT.  It
is
           reserved for the DOS SUBDIRECTORY flag. */
        FILE_ATTR_ARCHIVE               = const_cpu_to_le32(0x00000020),
        FILE_ATTR_DEVICE                = const_cpu_to_le32(0x00000040),
        FILE_ATTR_NORMAL                = const_cpu_to_le32(0x00000080),
                                                                                
        FILE_ATTR_TEMPORARY             = const_cpu_to_le32(0x00000100),
        FILE_ATTR_SPARSE_FILE           = const_cpu_to_le32(0x00000200),
        FILE_ATTR_REPARSE_POINT         = const_cpu_to_le32(0x00000400),
        FILE_ATTR_COMPRESSED            = const_cpu_to_le32(0x00000800),
                                                                                
        FILE_ATTR_OFFLINE               = const_cpu_to_le32(0x00001000),
        FILE_ATTR_NOT_CONTENT_INDEXED   = const_cpu_to_le32(0x00002000),
        FILE_ATTR_ENCRYPTED             = const_cpu_to_le32(0x00004000),
                                                                                
        FILE_ATTR_VALID_FLAGS           = const_cpu_to_le32(0x00007fb7),
        /* Note, FILE_ATTR_VALID_FLAGS masks out the old DOS VolId and
the
           FILE_ATTR_DEVICE and preserves everything else.  This mask is
used
           to obtain all flags that are valid for reading. */
        FILE_ATTR_VALID_SET_FLAGS       = const_cpu_to_le32(0x000031a7),
        /* Note, FILE_ATTR_VALID_SET_FLAGS masks out the old DOS VolId,
the
           F_A_DEVICE, F_A_DIRECTORY, F_A_SPARSE_FILE,
F_A_REPARSE_POINT,
           F_A_COMPRESSED, and F_A_ENCRYPTED and preserves the rest.
This mask
           is used to to obtain all flags that are valid for setting. */
                                                                                
        /*
         * The following flags are only present in the FILE_NAME
attribute (in
         * the field file_attributes).
         */
        FILE_ATTR_DUP_FILE_NAME_INDEX_PRESENT   =
const_cpu_to_le32(0x10000000),        /* Note, this is a copy of the
corresponding bit from the mft record,
           telling us whether this is a directory or not, i.e. whether
it has
           an index root attribute or not. */
        FILE_ATTR_DUP_VIEW_INDEX_PRESENT        =
const_cpu_to_le32(0x20000000),        /* Note, this is a copy of the
corresponding bit from the mft record,
           telling us whether this file has a view index present (eg.
object id
           index, quota index, one of the security indexes or the
encrypting
           file system related indexes). */
};
                                                                                
typedef le32 FILE_ATTR_FLAGS;

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/



More information about the samba-technical mailing list