On Sep 24, 2013, at 4:55 PM, Charles Srstka wrote: > On Sep 24, 2013, at 4:47 PM, Ken Thomases <[email protected]> wrote: > >> I was not aware of those limitations. Thanks for enlightening me. It >> looks, though, like you could reconstruct a path by working your way back >> from the item through its ancestors, getting each name along the way, using >> ATTR_CMN_NAME and ATTR_CMN_PARENTID. Not graceful, but should work. > > Is there a way to get those attributes of the parent without doing searchfs() > all over again?
No, I don't expect so. > Because if you had to do an entire drive search for every ancestor, that > would quite likely take a *long* time to complete. I don't think that searchfs() _necessarily_ does a true full-drive search. Given a unique file ID (ATTR_CMN_FILEID) in the search criteria, the file system implementation could very well return in constant time. As I said earlier, logically it could be as fast as resolving a file reference URL to a file path URL, since that's what that amounts to. That said, I haven't investigated either by reading the source or by running tests. Regards, Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
