On Mon, Feb 06, 2012 at 05:04:45PM +0000, David Holland wrote:
> On Mon, Feb 06, 2012 at 09:51:19AM +0000, Emmanuel Dreyfus wrote:
> > Here is public disuccsion about extended attributs namespaces, following
> > a private request from yamt@
>
> Which of the two models does OS X use?
OS X doesn't directly support namespacing nor does it support a difference
in access. If a file has an extended attribute, a program can read and
write it.
Put another way, the whole API deals with "user" xattrs.
ls -l@ /
drwxr-xr-x@ 62 root wheel 2108 Feb 17 20:48 sbin
com.apple.FinderInfo 32
That's some of the output on my Lion system. Looking in ~/Downloads, we
see some other interesting EAs:
-rw-r--r--@ 1 wrstuden staff 8381161 Apr 2 2010 things_1.3.3.dmg
com.apple.diskimages.fsck 20
com.apple.diskimages.recentcksum 80
com.apple.metadata:kMDItemDownloadedDate 53
com.apple.metadata:kMDItemWhereFroms 166
com.apple.quarantine 74
So just make the whole API do "user" and you're set.
The OS X file systems that have "system" EAs and which I am familiar with
do not expose them using the normal EA APIs. HFS uses a special EA to
store a file's ACL, and you never see it (nor should you).
Xsan supports user, system, and system.inherited EAs. Everything that
comes from userland is a "user" EA. We use the "system" ones for Reverse
Path data, so we can get a path for a file descriptor. The
"system.inherited" ones are used by Quantum for their data migration work.
As above, just have the VFS layer handle "user" attributes. It's simpler
and I don't think anything else will be reliable.
Take care,
Bill
Attachment:
pgp24y_FSSdHh.pgp
Description: PGP signature