Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: HFS Questions
Message-ID: <20259@ucbvax.BERKELEY.EDU>
Date: Sun, 23-Aug-87 15:39:01 EDT
Article-I.D.: ucbvax.20259
Posted: Sun Aug 23 15:39:01 1987
Date-Received: Sun, 23-Aug-87 23:49:41 EDT
References: <1071@vu-vlsi.UUCP> <1560@apple.UUCP> <6923@dartvax.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Distribution: na
Organization: School of Education, UC-Berkeley
Lines: 18
Keywords: HFS, Launching Applications

Larry is right. An application can tell its volume because it is the default
volume at the time the application startss up.  All finders have done it this
way, and if you have a minifinder that doesn't, that minifinder is broken and 
should be discarded.

SFGetFile may well show a different folder. SFGetFile completely does not
care about the default volume. It is using CurDirStore, a global variable
holding a 4-byte dirId, not a WDrefNum, to figure out which directory to
display. SetVol has no effect on SFGetFile.

The correct way for an application to discover its volume is for it to do
GetVol(NIL, &myVol); early in its initialization. Sure you can write 
Launch()ers that cause this to break, but if you do, you are the one who has
broken things, not the application.

--- David Phillip Oster            --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu