Re: [PATCH] get/set FAT filesystem attribute bits

[Anton Altaparmakov]

> Nicholas Miell wrote:
> > On another note, NTFS-style xattrs (aka named streams) are unrelated to
> > Linux xattrs. A named stream is a separate file with a funny name, while
> > a Linux xattr is a named extension to struct stat.

This is incorrect.  NTFS has two different beasts:

- Extended Attributes (EAs) which are just like Linux xattrs and in
Windows a very similar API exists as in Linux for accessing them (on
NTFS volumes only - VFAT does not support EAs in Windows).

- Named streams for which you are pretty much correct that they are like
a file with a funny name but note that named streams share the same
inode as their parent (unnamed) stream.  And this is not just the inode
number, it is the same on-disk inode.  This means that the ACLs, dos
attributes, etc, are all valid for both the unnamed and all named
streams.  So you cannot for example allow user A to access the unnamed
stream but not some named stream and vice versa you cannot allow user B
to access some named stream but not the unnamed stream.  In Windows
these beasts are accessed as filename::namedstreamname and in Linux
there is no existing API to access named streams at all that I am aware
off.  Again, as EAs, in Windows named streams only are supported on NTFS
volumes - VFAT does not support them.

The major difference is that access to named streams is much faster on a
per-stream basis as they are separate entities, i.e. stream A and stream
B share the same inode but are otherwise accessed independently and are
stored independently on disk (and as such can be read/written
simultaneously).  EAs on the other hand are all linked together and are
in fact just one large blob of data.  Resizing one EA modifies
potentially all of them since all EAs are stored in a single byte
stream, not very dissimilar to a named stream in fact.  So EAs are more
suited for storage of constant length structures while named streams are
better suited for variable length data (e.g. icons for executables, name
of document author, etc).

One interesting bit of trivia is that Windows uses named streams very
extensively while it _never_ uses EAs.  In fact I have never seen a
Windows OS or application that uses EAs.  They were added to be
compatible with OS/2 EAs when it came out but since OS/2 died they now
just seem like old baggage/backwards compatibility in Windows that is no
longer used.  (If anyone knows of a Windows application that uses EAs
please let me know.  I would be most interested in knowing about it!)

Hope this clears things up a bit as far as NTFS is concerned...

I don't know what API would be best for accessing named streams on NTFS
but an xattrs like interface is not suitable IMO.  You really want to be
able to open them and access them like normal files.  An interface
similar to the Solaris openat() system call (see
http://docs.sun.com/app/docs/doc/816-0212/6m6nd4nc7?a=view) that has
been discussed on LKML before seems like a good way to deal with this
but I am more interested in getting normal write support into NTFS at
present than I am in fancy features like EAs and named streams...

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/