fitzgerd@psu-cs.UUCP (Don Fitzgerald) (02/17/89)
I have bumped into what I think is a very interesting situation. After a call to GetVol I get a volume reference number for my HD20 which seems reasonable.
A few lines later I make a call to PBHGetVInfo and ioVRefNum gives me a
different Number ! I had set ioVolindex as one and there were not any other
volumes mounted. Hmmm interesting.
After a slight moment of fustration I consulted IM Vol IV and found out about
the VCB Block, quickly grabbed myself a ptr to look at with GetVCBQHdr and
proceeded to unHash this mystery with LSP 2.0's LightsBug1 (A very nice tool
for Pascal Programmers !!). Low and behold the queue contained exactly what
PBHGetVInfo had returned. After several tries the error remained consistant.
So there aremy questions. If the VCB Block contains the information that
GetVol and PBHGetVInfo look at how did they get different answers? How
does a person go about finding unique identifiers for volumes in the presence
of Multifinder?
To Compile or To Delete that is the question,
Donwert@cup.portal.com (robert scott comer) (02/21/89)
io ref number confusion: probably you are being confused by working directories and volume reference numbers. Working directories are a hack to make non-hfs aware programs (most of them) work like they did under the old flat file system. The GetVol system call returns a WDRefNum which works like a vRefNum, except that it carries a directory with it. StdFile returns these when you select a subdirectory on a volume. Cute, huh? scott out
tim@hoptoad.uucp (Tim Maroney) (02/21/89)
In article <1668@psu-cs.UUCP> fitzgerd@psu-cs.UUCP (Don Fitzgerald) writes: >I have bumped into what I think is a very interesting situation. After a call >to GetVol I get a volume reference number for my HD20 which seems reasonable. >A few lines later I make a call to PBHGetVInfo and ioVRefNum gives me a >different Number ! I had set ioVolindex as one and there were not any other >volumes mounted. Hmmm interesting. Once again the weirdness of HFS bites the unwary traveller. GetVol returns a working directory reference number, which pretends to be a volume reference number but is in fact a volume/directory pair. PBHGetVInfo returns the actual volume reference number. Both are behaving correctly. Because there still seems to be a lot of misunderstanding about working directories (three years later), a brief summary is in order. The original Mac had a flat file system; all the files in a volume were at the top level, and the folders were rather unconvincing fictions which only the Finder could see. Bad design, but that's neither here nor there. When the HD20 came out, there was an obvious need for a real hierarchical file system, but it had to be compatible with existing software. The Standard File Package used by users to select files returned only a name and a volume reference number (and a type), so somehow the volume/directory pair had to be crammed into the volume reference number. They did this by creating working directory reference numbers, which look like volume reference numbers and can be used in all the old file system calls that take a volume reference number, but they actualy refer to an internal table holding a volume/directory pair. All the old (non-"H") traps use these now, including GetVol and SetVol. I am sorely tempted to complain about the initial bad design; if part of the Mac design team realized the need for folders, how could they possibly fail to require them of the file system team? But this would serve no purpose, I suppose. We're stuck with the current cleverly hacked system. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Americans will buy anything, as long as it doesn't cross the thin line between cute and demonic." -- Ian Shoales