Re: Unified Carbon interface for extended attributes?
Re: Unified Carbon interface for extended attributes?
- Subject: Re: Unified Carbon interface for extended attributes?
- From: Quinn <email@hidden>
- Date: Wed, 20 Feb 2008 20:59:44 +0000
At 9:19 -0800 20/2/08, Kevin Hoyt wrote:
Quinn <email@hidden> wrote on 02/20/2008 08:37:31 AM:
> These are not accessible via the extended attribute API.
So we still need to use the Carbon APIs to get this information...
or resort to getattribute()...
Much of the information is available via <x-man-page://2/stat>. If
you want more, you'll have to use <x-man-page://2/getattrlist>.
Looks like I need to review this... I know that I hit a limit on MY
xattrs around 3800 bytes.
Just to confirm, the resource fork is treated as a special case
within the kernel and within HFS Plus. Both of them allow the
resource fork to be big but expect other extended attributes to small.
Just checking... when you say File Manager, you mean FSOpenFork()
and FSReadFork()?
Yes. File Manager is the API defined in "Files.h" in the CarbonCore
subframework of the CoreServices framework.
If we consider just 10.4 and above, isn't the AppleDouble file now a flat file
with an xattr for the resource fork? When would this NOT be the case???
What happened to all those AppleDouble files from prior OS levels?
When brought over to 10.4+, will the xattr functions come back with the
resourcefork as expected??
If the xattr for the resource fork is used to recreate a file, will it
become a flat file with xattr? Meaning, it is no longer an
AppleDouble file...
[...]
So this means that not all volumes support resources forks as xattr.
In turn, this means that we'd either have to maintain two different
approaches to accessing the data or stick with the lowest common
denominator... a mishmash of BSD and the File Manager API.
OK, I seem to have confused you. I'm sorry.
The underlying storage mechanism for this metadata has not changed
since Mac OS X 10.0.
o the data fork is always held in the standard place
o the resource fork, Finder info, and, since 10.4, the extended
attributes and the ACL, are stored in one of two places:
- natively, in a format determined by the VFS plug-in
- in an AppleDouble file
HFS Plus (and AFP) store this information natively. Most other file
systems need an AppleDouble file.
What has changed is the way you get at this information:
o Prior to 10.4 the only consistent way of getting at this
information was via File Manager. If you were working at the BSD
level, you would have to use getattrlist on file systems that stored
this information natively, and parse AppleDouble files on those that
didn't. File Manager was the abstraction layer that handled both of
these cases.
btw Parsing these AppleDouble files is not something we support.
While the AppleDouble format is nominally documented, the file
system's use of AppleDouble cuts some corners that we don't want to
document or support outside of this context.
o In 10.4 we added BSD-level extended attribute APIs, with the
implementation residing in the kernel. When you do a getxattr call,
the kernel will ask the VFS plug-in to handle it natively and, if
that's not supported, the kernel will do the AppleDouble thing.
This means that on 10.4.x it is possible to use BSD-level APIs to
copy a file and maintain its extended attributes.
Curiously, in 10.4.x the File Manager was not changed to take
advantage of this facility; rather, it works the same way as it did
prior to 10.4. This meant there was two subsystems handling
AppleDouble files. Needless to say this caused some interesting
problems.
Also, the kernel did not provide stream access to the resource fork.
You could get and set the resource fork via the extended attributes
API, but you could not open a file descriptor to the resource fork on
all file systems. The "foo/..namedfork/rsrc" trick would work on
volumes that supported the resource fork natively, but would not work
on volumes that stored the resource fork in an AppleDouble file.
o In 10.5 we got rid of the File Manager's AppleDouble code. File
Manager now (more-or-less) treats all volumes the same. The
implementation of the native/AppleDouble abstraction layer is now
done entirely within the kernel.
This means that, when you access metadata via BSD APIs, you're
accessing through exactly the same API that File Manager uses.
Neat-o! It also means that you can do the "..namedfork/rsrc" trick
on all volumes [1]. For example:
$ # Dump the resource fork of the stub Finder in /S/L/CoreServices.
$ hexdump -Cv /System/Library/CoreServices/Finder/..namedfork/rsrc
[...]
$ # Copy it to a MS-DOS/FAT volume.
$ cp /System/Library/CoreServices/Finder /Volumes/DOSFAT/
$ # Dump the resource fork there. It works!
$ hexdump -Cv /Volumes/DOSFAT/Finder/..namedfork/rsrc
[...]
I hope this all makes sense. If not, please post back and I'll
prattle on some more (-:
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] Those of you with experience programming kernels will now be shuddering (-:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden