Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!hao!ames!ucbcad!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac
Subject: Re: HFS Query
Message-ID: <2496@hoptoad.uucp>
Date: Wed, 22-Jul-87 23:26:26 EDT
Article-I.D.: hoptoad.2496
Posted: Wed Jul 22 23:26:26 1987
Date-Received: Sat, 25-Jul-87 03:31:27 EDT
References: <1020@runx.ips.oz>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Centram Systems, Berkeley
Lines: 51

In article <1020@runx.ips.oz> clubmac@runx.ips.oz (Jason Haines) writes:

>I have a program which has a list of datafiles, containing filename and the
>directory ID in which the file lives, rather than keeping a full pathname.
>
>Since I am using Lightspeed C's stdio routines, I need to be able to get a
>VRefNum (or WDRefNum) from the dirID, so that it can be plugged into SetVol().
>Then I can simply call fopen(fName,"r").

This approach is harder than it needs to be.

First, you really ought not to store directory IDs and expect them to remain
fixed.  I know, I know, this is explicitly stated to be legal.  However, if
you read the AFP (AppleShare protocol) documentation, you will see that AFP
supports or may support in the future volume types with non-fixed directory
IDs - IDs that are fixed only for the duration of a remote mount.  This is
because most OSs don't have directory IDs and it is a pain to implement them
for non-Mac AFP implementations.  So the long and the short of it is that if
you store dirids, you are asking to be incompatible with Appleshare at a
future date.  To be safe, you should store full path names.

Second, assuming that you go ahead and store volume name + directory id +
file name triplets for some reason, it is inconvenient to use SetVol to do
the changing of the directory.  SetVol would have to be given a working
directory reference number, meaning you would have to create a working
directory just for the operation and then delete it afterwards.  The working
directory calls crash the system on MFS systems, and are among the most
headachey routines of HFS anyway.  Instead, you should simply use the HFS
call PBHSetVol, which works fine on MFS systems and doesn't require diddling
around with working directories.

Third, you should reconsider your decision to use standard i/o routines for
an application that does anything seriously with HFS.  You will have to
(absolutely have to) mix two styles of file system calls in one program,
which is just asking for trouble.  What is wrong with the "low-level" File
Manager calls?  I find them easier to use than the "higher-level" ones,
since there is no need to remember argument order and if you need a little
more power it's right there waiting to be used.  You should dispense with
the fopen call entirely, and use PBHOpen to do your file opening.  (The only
problem is that you'll have to define your own OpenParam data structure,
since neither HIOParam nor HFileParam has all the neccessary fields, and
using a union is a major pain.)  This will also avoid the need to save and
restore directory id and volume around the open call, since you can just
specify the volume and directory id in the call without chaging defaults.

(Note though, that if you go with full pathanmes, you can continue to use
the fopen call, and dispose of the SetVol.  HFS calls will still be neede to
construct the full pathnames, though.)
-- 
Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)