Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!clubmac
From: clubmac@runx.ips.oz (Macintosh Users Group)
Newsgroups: comp.sys.mac
Subject: Re: HFS Query
Message-ID: <1033@runx.ips.oz>
Date: Mon, 27-Jul-87 22:01:30 EDT
Article-I.D.: runx.1033
Posted: Mon Jul 27 22:01:30 1987
Date-Received: Sun, 2-Aug-87 09:54:27 EDT
References: <1020@runx.ips.oz> <2496@hoptoad.uucp>
Reply-To: clubmac@runx.OZ (Macintosh Users Group - Sydney, Australia)
Organization: RUNX  Un*x Timeshare. Sydney, Australia.
Lines: 76

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