Re: How to best store references to disk items, not using paths?
Re: How to best store references to disk items, not using paths?
- Subject: Re: How to best store references to disk items, not using paths?
- From: Quinn <email@hidden>
- Date: Fri, 13 Mar 2009 10:45:23 +0000
At 15:31 +0100 12/3/09, Thomas Tempelmann wrote:
Uh, I just realized that PBResolveFileIDRefSync() has become
deprecated in 10.5.
Along with all the other FSSpec stuff, it was deprecated as part of
the 64-bit effort. At the same time we added FSRef-based
equivalents, in this case FSResolveNodeID.
If you want to temporarily track a small number of files, the best
way to do so is to open file descriptors for them. This gives you a
whole bunch of options that aren't available otherwise.
However, it seems you want to track a large number of files. In that
case file descriptors won't do (because you'll run out of them). I
recommend that you split your code:
o For volumes which have traditional Mac semantics, use catalogue
node IDs (CNID, returned as inode numbers at the BSD level) and
resolve them using FSResolveNodeID. Currently there is no way to do
this resolution at the BSD level. QA1113 covers this in some detail
and, although the mechanics did change in 10.5, the Q&A's conclusion
is still valid.
<http://developer.apple.com/qa/qa2001/qa1113.html>
To detect volumes like this, check for
VOL_CAP_FMT_PERSISTENTOBJECTIDS. While you don't need persistent
object IDs, volumes that support them are likely to deal with this
sort of stuff well (whereas volumes that /don't/ support persistent
IDs are likely to be using some sort of compatibility goo that causes
you problems).
o For volumes which have traditional UNIX semantics, some some other
technique that's based on file names (and hence paths) rather than
inode numbers.
As soon as you start trying to use CNID concepts on UNIX-style
volumes, you encounter both extra overhead and wacky compatibility
issues. It's better not to even try IMO.
Specifically, a traditional UNIX inode number is /not/ comparable to
a traditional Mac CNID. A CNID carries with it a promise of uncommon
reuse, whereas an inode number doesn't. You can use inode number's
generation to get roughly equivalent behaviour, but it's impossible
to access that value from non-privileged code.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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