Re: Unified Carbon interface for extended attributes?
Re: Unified Carbon interface for extended attributes?
- Subject: Re: Unified Carbon interface for extended attributes?
- From: Kevin Hoyt <email@hidden>
- Date: Wed, 20 Feb 2008 09:19:42 -0800
Quinn <email@hidden> wrote on 02/20/2008
08:37:31 AM:
> 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.
So we still need to use the Carbon APIs to get this information... or resort
to getattribute()...
>
> >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.
>
So we do have a choice on this one...
It is possible to read the data fork via BSD calls
and still get the
resource fork as an xatter... good to know!
> >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.
so the xatter could be mapped to the same structures
we use today... good!
>
> 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.
Looks like I need to review this... I know that I
hit a limit on MY xattrs around 3800 bytes.
>
> >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.
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...
>
> 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).
Just checking... when you say File Manager, you mean
FSOpenFork() and FSReadFork()?
>
> 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.
Well, for AppleDouble files... what about those end
users that like ._ for their files?
If I skip those, I can't restore them...
(yes, this is me being a pain :-)
>
> 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>.
>
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.
> S+E
> --
> Quinn "The Eskimo!"
<http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Kevin Hoyt _______________________________________________
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