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)