• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unified Carbon interface for extended attributes?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Unified Carbon interface for extended attributes?
      • From: James Bucanek <email@hidden>
References: 
 >Unified Carbon interface for extended attributes? (From: James Bucanek <email@hidden>)

  • Prev by Date: Re: Determining if a volume support
  • Next by Date: Re: Determining if a volume support
  • Previous by thread: Unified Carbon interface for extended attributes?
  • Next by thread: Re: Unified Carbon interface for extended attributes?
  • Index(es):
    • Date
    • Thread