Carbon File Mgr vs POSIX performance regarding hard links - conclusion
Carbon File Mgr vs POSIX performance regarding hard links - conclusion
- Subject: Carbon File Mgr vs POSIX performance regarding hard links - conclusion
- From: Thomas Tempelmann <email@hidden>
- Date: Sun, 04 May 2008 19:12:50 +0200
- Thread-topic: Carbon File Mgr vs POSIX performance regarding hard links - conclusion
I've finally figured out what's going on with accessing hard links via the
Carbon File Mgr functions such as FSGetCatalogInfo and FSCatalogSearch:
The functions _resolve_ hard links automatically but do not return the hard
link's inode number in any field of FSCatalogInfo.
TN 1150 (http://developer.apple.com/technotes/tn/tn1150.html#HardLinks)
explains that a dir entry that's a hard link has particular values such as a
special fileType and fileCreator, and holds the inode number in a field of
the permissions. However, these values are not returned in the FSCatalogInfo
when calling the File Mgr functions. Instead, the hard link entry gets
resolved, i.e. the "inode" entry gets looked up, and its contents are then
returned in the FSCatalogInfo - well, not all those contents, either: the
union field holding the inode number of the hard link count in the on-disk
structure returns a rather random value.
Hence, there is simply no clean & fast way thru the Carbon File Mgr API to
group items by their identical inode since there is no inode-related value
returned.
As I had shown in my original post, the use of lstat() to get the inode
value works, but makes the process awfully slow because the lookup of the
file/folder using a POSIX path slows the access down drastically.
Someone else suggested to try using fstat() on an opened file, but this
won't work on a Time Machine backup volume too well because most hard links
there are folders, which can't be opened as files for this trick, I'm
afraid.
I might as well try reading the catalog file directly myself.
Hm, maybe it's time to dig out Amit Singh's book again...
Thanks to all who sent suggestions, even though they didn't help much in the
end with my problem.
Thomas
_______________________________________________
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