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: Nicholas Miell <nmiell@comcast.net>,
	hirofumi@mail.parknet.co.jp, lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] get/set FAT filesystem attribute bits
Date: Tue, 04 Jan 2005 10:09:17 +0000	[thread overview]
Message-ID: <1104833357.26349.21.camel@imp.csi.cam.ac.uk> (raw)
In-Reply-To: <41D9C111.2090504@zytor.com>

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


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

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 20:57 H. Peter Anvin
2005-01-03 21:24 ` Nicholas Miell
2005-01-03 21:35   ` H. Peter Anvin
2005-01-03 21:46     ` Nicholas Miell
2005-01-03 22:02       ` H. Peter Anvin
2005-01-03 22:10         ` Nicholas Miell
2005-01-03 22:25           ` H. Peter Anvin
2005-01-03 23:16             ` Nicholas Miell
2005-01-03 23:22               ` H. Peter Anvin
2005-01-03 23:46                 ` Nicholas Miell
2005-01-04 10:09         ` Anton Altaparmakov [this message]
2005-01-04 21:45           ` Nicholas Miell
2005-01-04  8:34 ` OGAWA Hirofumi
2005-01-04  9:41   ` H. Peter Anvin
     [not found] <fa.ea9o20r.kje5qn@ifi.uio.no>
     [not found] ` <fa.lub44op.a2ec2d@ifi.uio.no>
2005-01-04 11:57   ` Bodo Eggert
2005-01-04 21:26     ` H. Peter Anvin
     [not found] <fa.i537e7s.1d6m90c@ifi.uio.no>
     [not found] ` <fa.ihdqkec.1i5umji@ifi.uio.no>
2005-01-06  0:07   ` Bodo Eggert
2005-01-06  1:35     ` H. Peter Anvin

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=1104833357.26349.21.camel@imp.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmiell@comcast.net \
    /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®