Path: utzoo!attcan!uunet!tank!ncar!asuvax!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!paperboy!snorkelwacker!apple!well!brecher
From: brecher@well.sf.ca.us (Steve Brecher)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Prefered Way to Refer to Files...
Keywords: File Manager
Message-ID: <16681@well.sf.ca.us>
Date: 14 Mar 90 09:13:26 GMT
References: <38534@cornell.UUCP>
Reply-To: brecher@well.sf.ca.us (Steve Brecher)
Distribution: comp
Organization: Software Supply, Sunnyvale, CA
Lines: 55


In article <38534@cornell.UUCP>, wayner@svax.cs.cornell.edu (Peter Wayner)
writes:
> I've been coding up an application which needs to keep a list of files
> and their locations on the disk. This list needs to be stable from boot
> to boot and even between restores from backup. There are several ways
> this can be done:
> 
> 1) Full Path name
> 2) file name and DirId
>

2) should be volume name, file name, and DirID.

> Tech Note #240 something says that path names are not as robust as
> directory ids because directory ids are preserved when directories are
> moved. On the other hand, it admits that restoring a file from backups
> will probably not preserve Directory Id's.
> 
> My questions are;
> 
> Are there any other problems with pathnames?

The other problem with pathnames is that they may exceed 255 bytes in
length, which may make them difficult to use.

The best approach would be to store both (1) and (2), with code to
handle the 256+ length problem mentioned above.  When accessing the
file, use (2); if that works, update (1).  If (2) doesn't work, use (1)
and update (2). However, few if any products actually do this; my own
current products use (2) only.  One of them (PowerStation) has a command
to search all online disks for "lost" files, as typically occurs after
an initialize/restore.

> How can I convert a DirId into a vRef which I can then use with [FSOpen]?
> Or more generally, how can I open a file with a name and a DirId?

As noted above, you will nead a volume specifier in addition to file
name and DirID.  Instead of using FSOpen, you can use PBHOpen.  But to
answer the question:  you would create a WD with OpenWD, and then pass a
WDRefNum instead of a VRefNum to FSOpen.  Since WDs occupy a system-wide
table of limited size, you would clean up afterwards with CloseWD.

> What about System 7.0? The tech note mentions that file id numbers will
> be the best when System 7.0 comes around because they will be stable
> even after renaming.

Right, but it ain't here yet; also, you will probably want your
application to run under earlier systems.  In a couple of years or so it
will be feasible to require System 7 or later, just as circa 1988 it
became feasible to require the Mac Plus feature set (introduced in early
1986).
-- 

brecher@well.sf.ca.us (Steve Brecher)