brian@natinst.com (Brian H. Powell) (05/11/89)
Near as I can tell from Inside Mac, working directories are temporary
objects. (E.g., IV-98: "It's [A WD is] a temporary reference number that
specifies where a file is located on a hierarchical volume".)
A quick tutorial on working directories: WD's are 16 bits, and they're
trying to cram 48 bits of information into them (the vol and dirID). WD's
exist for backwards compatibility, since the old MFS vRefNum was 16 bits.
Basically, you have a set of "open" working directories that the 16-bit WD
refers to. Ideally, this 16-bit WD would be a permanent entity; no matter
when a particular piece of code executes, if it's got a WD, it knows exactly
what vol/dirID the code wants. But you can't leave all of the working
directories you've used open in theory, since you can potentially have more
than 16-bits worth of directories. So, WD's must go "stale" at some point.
When does a WD go stale? Does it last for an entire application's
execution lifetime?
Our problem is that in our program, a user may run SFGetFile or SFPutFile
(returning a WD), and only at a much later time actually try to open the file.
One option is to immediately turn the WD into a vol/dirID pair, but that
creates a little extra overhead (which in our program puts a little extra
burden on the user.)
Thanks for any help with this.
Brian H. Powell National Instruments Corp.
brian@natinst.com 12109 Technology Blvd.
uunet!cs.utexas.edu!natinst!brian Austin, Texas 78727-6204
AppleLink:NATINST (512) 250-9119