clubmac@runx.ips.oz (Macintosh Users Group) (07/20/87)
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").
Any ideas?
Thanks in advance,
Jason Haines
Club President
Club Mac Macintosh Users Group, Sydney, Australia
Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia
ACSnet: clubmac@runx.ips.oz ARPA: clubmac%runx.ips.oz@seismo.css.gov
UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.ips.oz!clubmactim@hoptoad.uucp (Tim Maroney) (07/23/87)
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)
jww@sdcsvax.UCSD.EDU (Joel West) (07/23/87)
In article <2496@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
. 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.
One such OS is A/UX, where the stored IDs are explicitly stated to be
illegal. Even without AppleShare, if you run on A/UX, stored id's won't
work.
--
Joel West, Palomar Software, Inc. (c/o UCSD)
{ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edulsr@apple.UUCP (Larry Rosenstein) (07/23/87)
In article <2496@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >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. The working directory calls are not implemented on MFS systems. On MFS disks, there is no problem because there are no folders. I agree that it is inconvenient to create a working directory, but it is not very difficult to test whether HFS is installed. Tech Note 140 (just released) cautions agains using PBHSetVol. The reason is that if you pass a dirID to PBHSetVol, the File Manager stores it separately from the volume refnum. If you (or some DA) then call GetVol (or PBGetVol) all you will get back is the volume refnum. This is particularly bad for DAs, since they cannot know that you have called PBHSetVol. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
clubmac@runx.ips.oz (Macintosh Users Group) (07/28/87)
In article <2496@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >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. > Yes, but the whole problem with storing a full path name to a file is that a user may change the name of an HFS folder, thus making the file inaccessible >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. > I have made the assumption that MFS is no longer a valid file system - the base machine is now a MacPlus, and anyone that doesn't upgrade their 512K with the 128K ROMs isn't interested in spending money to buy my program. Thanks to some help from a friend, I discovered that the simplest way of calculating a WDRefNum was to call PBOpenWD() with procID set to 'ERIK'. By setting the procID to 'ERIK', I know that when I open the file in the volume in question, HFS will not duplicate working directory entries, using the one I created when I made the WDRefNum calculation. >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. > I think Apple would prefer me to use the high-level File Manager calls as much as possible - to avoid the inevitable changes to the Filing System that will make code using low-level calls fall over. I seem to be placed between a rock and a hard place. Full pathnames are out because the user can change the folder names as much as he/she likes. And good ol' directory IDs are not so stable... Perhaps Larry Rosenstein et al could offer a solution? Furthermore, I think the use of a singular means of identifying a directory ( a directory ID ) was extremely short-sighted of the HFS-makers. It makes AppleShare seem like an afterthought. To me, these directory IDs seemed like lighthouses in the sea of HFS confusion. Now, these stable anchors are going to soon flutter in the wind... Valium, anyone? Jason Haines Club President Club Mac Macintosh Users Group, Sydney, Australia Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia ACSnet: clubmac@runx.ips.oz ARPA: clubmac%runx.ips.oz@seismo.css.gov UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.ips.oz!clubmac
olson@endor.harvard.edu (Eric Olson) (08/03/87)
In article <1033@runx.ips.oz> clubmac@runx.OZ (Macintosh Users Group - Sydney, Australia) writes: >Thanks to some help from a friend, I discovered that the simplest way of >calculating a WDRefNum was to call PBOpenWD() with procID set to 'ERIK'. By >setting the procID to 'ERIK', I know that when I open the file in the volume >in question, HFS will not duplicate working directory entries, using the one >I created when I made the WDRefNum calculation. You also don't have to close WDs opened with a ProcID of 'ERIK'. They are all closed by the system at some point (probably during ExitToShell). This is the ProcID that Standard File uses when it opens a WD to pass to programs as a VRefNum. -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson