How to best store references to disk items, not using paths?
How to best store references to disk items, not using paths?
- Subject: How to best store references to disk items, not using paths?
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 12 Mar 2009 15:08:52 +0100
I am looking at the extended BSD FS calls, such as getattrlist.
I like to store a lot of file references inside my app, for items on
mounted volumes.
Up to now, I used FSRefs to store the refs, but I learned at WWDC that
FSRefs cause caching problems when referencing remote volumes, leading
to inefficiency.
While 10.6 may introduce better ways to keep refs to files, I need a
working solution now for 10.4 and 10.5.
I don't want to use paths for various reason - let's not get into a
discussion about it.
I found that getattrlist() offers me two other options:
1. ATTR_CMN_OBJID gives me a 32 bit reference, which is not guranteed
to be persistent past an unmount (which is fine for me).
2. ATTR_CMN_FILEID gives me a 64 bit ref, but without further
information about its persistence and other possible conditions.
The fact that there are 64 bit IDs suggests that we may encounter them
one day, maybe even now already with advanted file systems (ZFS,
maybe?).
Looking at xnu sources I find that even when accessing the 64 bit file
ID fields, only its lower 32 bit are actually taken.
This suggests that 10.5 can not support file systems with more than 4
gig items, correct?
I wonder if 10.6 changes that - I'll ask that on a different list
where it's more appropriate (as infos on it are still under NDA,
mostly).
So, assuming that I have to deal with 32 bit ID only for now, I have
these questions:
a) is either of above attributes better than the other for performance
(i.e. does either of them suggest that the file system has a way to
directly locate the item in the directory without the need for
excessive search or need for caching tables)?
b) I cannot find a BSD function that gives me the path or other
attributes based on an ID. I know such must exist, as to support the
similar Carbon function, but the man pages are not very helpful with
that, not providing such cross-references.
--
Thomas Tempelmann, http://www.tempel.org/
_______________________________________________
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