lkml.org 
[lkml]   [2005]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: FAT, NTFS, CIFS and DOS attributes
    From
    Date
    On Tue, 2005-01-04 at 10:34 +0000, Anton Altaparmakov wrote:
    > 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!

    I meant definitely not the second suggestion of c (i.e. the string
    subset). That is just horrible...

    > 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):

    Another reason to want 32-bits is that this could be used to add more
    Linux specific bits like "FILE_ATTR_CHAR_DEV" for character device
    special files and use the existing "FILE_ATTR_DEVICE" for block devices.
    Windows unfortunately does not distinguish between the two in the
    flags. )-:

    > /*
    > * 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/

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

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.034 / U:1.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site