Re: Unified Carbon interface for extended attributes?
Re: Unified Carbon interface for extended attributes?
- Subject: Re: Unified Carbon interface for extended attributes?
- From: James Bucanek <email@hidden>
- Date: Tue, 19 Feb 2008 08:46:36 -0700
Quinn <mailto:email@hidden> wrote (Tuesday, February 19,
2008 3:22 AM -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).
Sorry, this is a backup and document archiving program: Files ->
Proprietary data format -> Files
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.
I'm getting that impression.
Please don't confuse the Launch Services attributes namespace with the
extended attributes namespace. They aren't related in any way.
Thanks, I was got that impression because this was the function
provided to get some of the new extended attributes in 10.5
(like kLSItemQuarantineProperties). I assumed that this was the
Carbon interface to the extended attributes. My bad.
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.
Thanks for this technique. I was afraid I've have to call
FSRefMakePath on every file. I'll profile this and see what the
performance is like.
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.
Sadly, this just isn't the case. There's a definite schism
between the File Manager APIs and the BSD APis. Launch services,
some metadata, icons, traditional file type/creator, creation
dates, etc. all need FSRefs. Now it looks like extended
attributes can only be accessed via BSD (as are other problems
like identifying and recreating hard links).
So iterating files using the BSD interfaces really won't help
much, not to mention that I've already got 100,000 lines of
working code and an entire application architecture oriented
around FSRefs. To get all of the information about a file I
either have to convert each FSRef into a BSD path, or each BSD
path into and FSRef.
--
James Bucanek
_______________________________________________
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