mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: sfrench@samba.org,
	ntfs-dev <linux-ntfs-dev@lists.sourceforge.net>,
	samba-technical@lists.samba.org, hirofumi@mail.parknet.co.jp,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: FAT, NTFS, CIFS and DOS attributes
Date: Tue, 04 Jan 2005 10:34:25 +0000	[thread overview]
Message-ID: <1104834865.26349.32.camel@imp.csi.cam.ac.uk> (raw)
In-Reply-To: <41D9C635.1090703@zytor.com>

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/


  parent reply	other threads:[~2005-01-04 10:35 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 22:24 H. Peter Anvin
2005-01-03 23:26 ` Michael B Allen
2005-01-03 23:33   ` H. Peter Anvin
2005-01-03 23:48     ` Michael B Allen
2005-01-03 23:55       ` H. Peter Anvin
2005-01-04  0:18     ` tridge
2005-01-04  0:24       ` H. Peter Anvin
2005-01-04  0:39         ` tridge
2005-01-04  0:57           ` H. Peter Anvin
2005-01-04  1:12             ` tridge
2005-01-04  1:31         ` Nicholas Miell
2005-01-04  1:48           ` H. Peter Anvin
2005-01-04  2:05             ` Nicholas Miell
2005-01-04 22:24       ` [Linux-NTFS-Dev] " Szakacsits Szabolcs
2005-01-04  1:21   ` tridge
2005-01-04  1:30     ` H. Peter Anvin
2005-01-03 23:28 ` Nicholas Miell
2005-01-04  0:05 ` tridge
2005-01-04  0:30   ` H. Peter Anvin
2005-01-04  0:58     ` tridge
2005-01-04  1:14       ` H. Peter Anvin
2005-01-04  1:36         ` tridge
2005-01-04  1:50           ` H. Peter Anvin
2005-01-04  2:05             ` tridge
2005-01-04  2:09               ` H. Peter Anvin
2005-01-04  2:23               ` Kyle Moffett
2005-01-04  2:49                 ` tridge
2005-01-04  3:39                   ` Kyle Moffett
2005-01-04  3:56                     ` tridge
2005-01-04  4:50                       ` Kyle Moffett
2005-01-04  4:05     ` Michael B Allen
2005-01-04 10:34 ` Anton Altaparmakov [this message]
2005-01-04 11:08   ` Anton Altaparmakov
2005-01-04 22:18   ` Nicholas Miell
2005-01-04 23:04     ` Anton Altaparmakov
2005-01-05  0:48       ` Nicholas Miell
2005-01-05  1:12         ` Nicholas Miell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1104834865.26349.32.camel@imp.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®