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 16:37:31 +0000
At 7:44 -0800 20/2/08, Kevin Hoyt wrote:
Which of these are covered by the Extended Attribute for the finder?
kFSCatInfoTextEncoding
kFSCatInfoNodeFlags
kFSCatInfoCreateDate
kFSCatInfoContentMod
kFSCatInfoAttrMod
kFSCatInfoAccessDate
kFSCatInfoBackupDate
kFSCatInfoFSFileSecurityRef
kFSCatInfoDataSizes
These are not accessible via the extended attribute API.
kFSCatInfoRsrcSizes
This isn't really accessible via the extended attribute API, but you
can get part of the info (that is, the equivalent of rsrcLogicalSize)
by calling <x-man-page://2/getxattr> on the "com.apple.ResourceFork"
attribute and passing in a NULL buffer.
kFSCatInfoFinderInfo
kFSCatInfoFinderXInfo
These are accessible via the "com.apple.FinderInfo" extended attribute.
For those bits that are in the xattr, is it possible to extract those bits?
Is the format of the finder information in the extend attribute
public information?
Where is this documented?
There's no intrinsic difference between the Finder info you get back
via FSGetCatalogInfo[Bulk] and the Finder info you get back by
"com.apple.FinderInfo". The only gotcha is that the BSD routine
returns the data big endian, and the File Manager returns the data
native endian.
The format of the Finder info is partially documented. See the
structures in "Finder.h". Specifically FileInfo, FolderInfo,
ExtendedFileInfo, and ExtendedFolderInfo. Some fields have very well
defined meanings (like FinderInfo.fileType) and others are used by
the Finder in an undocumented way. If you're going to treat this
data as anything other than a bag o' bytes, it's a good idea to stick
to the well defined stuff.
As for the xattr for the resource fork. What is the limit on the
amount of data that xattr can contain?
There's no hard and fast limit but the practical limit for the size
of a resource fork is just over 16 MB.
In my testing of xattrs, I believe the limit is around 3800 bytes.
Is this also true for the resource forks?
No. Resource forks can be much bigger, bigger than we would like any
other extended attribute to be. Note that getxattr has a special
parameter, position, that's specifically present to allow you to read
the resource fork in chunks.
Is this limit documented???
Which one? (-:
Seriously, neither of them is well defined.
o In theory a resource fork could extend to the size of an off_t (64
bits, signed). However, the internal format of a resource fork
limits it to much less. The traditional limit is 16 MB (24-bits,
unsigned) but, if you structure your resource fork just so, it is
possible to go beyond that.
Oh, yeah, and if the resource fork is to be stored in an AppleDouble
file, it must be under 4 GB.
o The limit for other extended attributes is also not well defined.
In fact, its file system specific. In general, if you're storing
more than 1 KB in an extended attribute, you're in the weeds.
I realise that this response is too fuzzy to be of much use to a
backup developer. If you're creating backup software and you need to
settle on a serialised file format, I recommend at /least/ 2^63 bits
for all forks and at least 2^32 bits for each extended attribute.
On a UFS filesystem, the resource forks are separate flat files.
How can I tell that the file is a resource fork instead of some
random file named ._xxx?
This shouldn't matter. This breaks down as follows:
o Prior to Mac OS X 10.4, you should back up using the File Manager.
This is the only way to do complete backups without having to read
and write the internals of an AppleDouble file (something that we
definitely don't support).
o In Mac OS X 10.4 and later, you have the choice of using either
File Manager or BSD. In the BSD case, you should access all of this
stuff via the BSD extended attributes API. In the File Manager case,
you can can use either FIle Manager or the BSD extended attributes
API to get at the Finder info and resource fork, but you must use the
BSD extended attributes API to get at other extended attributes.
o The situation in Mac OS X 10.5 is mostly unchanged. The only new
wrinkle is that, if you're working at the BSD level and you want to
access the resource fork as a stream (as opposed to an extended
attribute), you can now do so (by appending "..namedfork/rsrc" to the
path).
In all cases, you should ignore AppleDouble files (those whose name
begin with "._") if you encounter them in the file system.
If you /really/ need to tell whether the volume supports native
extended attributes, you can test the VOL_CAP_INT_EXTENDED_ATTR
attribute. Read <x-man-page://2/getattrlist> to learn how to test
this. It doesn't specifically document this flag
<rdar://problem/5754459>, but the flag is a peer of
VOL_CAP_INT_USERACCESS so just look at that flag and extrapolate.
This flag wasn't defined prior to 10.5. On earlier systems the
support for extended attributes was intimately tied to the support
for file-to-path translation. A single flag was used to check for
both. That flag was MNT_DOVOLFS, as returned in the f_flags field
returned by <x-man-page://2/statfs>.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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