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: Tue, 19 Feb 2008 10:22:30 +0000
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>.
_______________________________________________
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