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 07:44:17 -0800
Interesting discussion...
Which of these are covered by the Extended
Attribute for the finder?
kFSCatInfoTextEncoding
kFSCatInfoNodeFlags
kFSCatInfoCreateDate
kFSCatInfoContentMod
kFSCatInfoAttrMod
kFSCatInfoAccessDate
kFSCatInfoBackupDate
kFSCatInfoFSFileSecurityRef
kFSCatInfoFinderInfo
kFSCatInfoFinderXInfo
kFSCatInfoDataSizes
kFSCatInfoRsrcSizes;
Assume for the moment that it's important
to be able to compare each attribute to a different version of the file...
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?
As for the xattr for the resource fork.
What is the limit on the amount of data that xattr can contain?
In my testing of xattrs, I believe the
limit is around 3800 bytes. Is this also true for the resource forks?
Is this limit documented???
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?
Message: 2
Date: Tue, 19 Feb 2008 10:22:30 +0000
From: Quinn <email@hidden>
Subject: Re: Unified Carbon interface for extended attributes?
To: email@hidden
Message-ID: <p06240821c3e0564896c1@[10.0.40.15]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 11:59 -0700 18/2/08, James Bucanek wrote:
>Any suggestions?
If you're copying a file, you can just use the File Manager copying
routines (FSCopyObjectSync and so on). These take care of all of
the
tricky stuff. Furthermore, these routines call down to the code
that's used by Finder and Time Machine, so your results will be at
least as good as that.
If you need to serialise a file, you can do so using
<x-man-page://3/copyfile>. I must say, however, that I'm not
a great
fan of this API. It just doesn't get as much use of the File Manager
code. Overall, I'd probably recommend that you use your own code
for
this [1].
To that end, it's relatively easy to serialise a file, at least on
10.4 and later. Here's roughly what you need to do:
A. get the data fork
B. get all extended attributes using <x-man-page://2/listxattr> and
<x-man-page://2/getxattr>
C. get the ACL
You can do steps A and C with either File Manager or BSD interfaces.
You can some of step B with File Manager interfaces (specifically,
copying the "com.apple.FinderInfo" and "com.apple.ResourceFork"),
but
you will need to drop to BSD to do it completely.
Step B will cover the traditional Mac OS metadata (the Finder info
and resource fork) and most modern metadata. For example, the
kLSItemInfoExtensionIsHidden is stored in one of the Finder flags, so
if you copy the "com.apple.FinderInfo" attribute, you will copy
this
as well.
At 11:59 -0700 18/2/08, James Bucanek wrote:
>- Some attributes returned by FSCopyItemAttributes don't appear as
>extended attributes when the file is queried using getxattr(). For
>example, kLSItemExtension will return an item's filename extension,
>while getxattr() returns nothing.
That's because the extension attribute is algorithmically determined
from the file name.
>- Developers are free to create their own extended attributes and
>attach them to files. The listxattr() interface will list all
>extended attributes for a file, but FSCopyItemAttribute(s) only
>accepts an a priori set of defined attribute names.
Correct. Please don't confuse the Launch Services attributes
namespace with the extended attributes namespace. They aren't
related in any way.
>There's no Carbon interface that I can find that will list or return
>all known attributes for a file.
Indeed. You will have to use BSD-level interfaces for this.
>It seems I can do this with listxattrs()/getxattr(), but that API is
>expensive for me because the files are being scanned via
>FSGetCatalogInfoBulk(). I'd have to convert every FSRef to a BSD
>path and then use listxattrs() to probe it. This wouldn't be too bad
>if there was some flag or bit in FSCatInfo that a file had one or
>more extended attributes, but I can't find any such indicator.
There is no such indicator.
OTOH, converting an FSRef to a path isn't as expensive as you might
think because you're getting the name of the file system object at
this point anyway. For example:
i) Maintain the path to the parent directory as you iterate the
hierarchy.
ii) Get the name of the file system object from FSGetCatalogInfoBulk.
iii) Convert that name to UTF-8 (and swap slashes to colons).
iv) Append it to the parent directory path.
Alternatively, do your iteration at the BSD level. Prior to 10.4
there was no good way to do stuff like this using BSD level code
because you couldn't access traditional Mac OS metadata easily from
that level. Since 10.4 that's not the case, and there's now very
little reason to use File Manager for this stuff.
S+E
--
Quinn "The Eskimo!"
<http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] For the Apple folks following along, consider <rdar://problem/5712224>.
Kevin Hoyt
Software Engineer, Tivoli Storage Manager, Client Development
ALMADEN RESEARCH CENTER
Dept M47A / Bldg C2-500-F06
650 HARRY ROAD, SAN JOSE CA 95120-6099
Notes: Kevin Hoyt/San Jose/IBM@IBMUS
Internet: email@hidden
Phone 408.927.2118
o^o o^o o^o o^o o^o o^o o^o o^o
o^o o^o _______________________________________________
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