kresch@vu-vlsi.UUCP (Ed Kresch) (08/20/87)
I have a few questions about HFS. I was unable to find the answers to
these questions in the first four volumes of Inside Macintosh. Any suggestions
you can provide will be greatly appreciated.
One note: when I refer to a vRefNum, I am talking about the volume
reference number/drive number/working directory reference number that can
be used to help access a file.
1. How can one determine the vRefNum of the application that is currently
running, from within the application?
2. If one creates temporary files, should they be in the same folder as
the application, in the system folder, or somewhere else? Is there
a standard for this, or is it the application's choice?
3. How do you store an absolute reference to a file: one that can be
saved in a datafile and loaded the next time the application is run
when different disks may be in each drive, new folders may have been
created, etc?
4. How do you find out the vRefNum of the system folder? Is it BootDrive,
or is BootDrive a reference to the root directory of the startup volume?
5. How does one determine if the vRefNum returned by SFGetFile or
GetAppFiles is a volume reference number or a working directory reference
number?
6. When an application starts up, are there any working directories?
7. How does Launch know which volume to launch the application from? I
looked at the code for ExitToShell and noticed that it just does a
Launch with the FinderName as the name, and does nothing as far as
volumes. Does that mean that an application must preserve the
default volume?
Thanks for you help.
Ed Kresch
Send responses to ...!{ cbmvax, pyrnj, bpa }!vu-vlsi!kresch.lsr@apple.UUCP (Larry Rosenstein) (08/20/87)
In article <1071@vu-vlsi.UUCP> kresch@vu-vlsi.UUCP (Ed Kresch) writes: > >1. How can one determine the vRefNum of the application that is currently > running, from within the application? The current volume (as returned by GetVol) will indicate the folder containing the application. This will be a wdRefnum if the application is inside a folder. >2. If one creates temporary files, should they be in the same folder as > the application, in the system folder, or somewhere else? Is there > a standard for this, or is it the application's choice? It depends. Applications can be launched from a server, so if you place it in the same folder as the app, it might end up on a server. The System Folder is guaranteed to be a local volume. On the other hand, the disk containing the System Folder might be very full if the user is running a floppy-based system. (If you wanted to get sophisticated, you would try several volumes until you find one that has enough disk space.) If you do place the file in the same folder as the application, make sure to give it a unique name, in case more than 1 user tries to run the application at the same time. >3. How do you store an absolute reference to a file: one that can be > saved in a datafile and loaded the next time the application is run > when different disks may be in each drive, new folders may have been > created, etc? One possibility is to store the full pathname to a file. The problem is that the user can change the name of any folder in the path very easily. (Also note that a full pathname might be longer than 255 characters, which would prevent you from passing it to HFS all at once.) You can get around this by storing the dirID of the folder containing the file, along with the name of the volume and name of the file. dirIDs are unique on a volume (until it is reformatted). The only problem is that some servers don't guarantee that dirIDs are constant each time you mount the server. (They create unique dirIDs while you have the server volume mounted, but not if you unmount & remount the server.) Since you have to store a volume and file name anyway, there will always be the possibility that the user will change the name, and your program won't be able to find the file. In this case, you should bring up a Standard File dialog, allow the user to find the file for you, and save its new location. >4. How do you find out the vRefNum of the system folder? Is it BootDrive, > or is BootDrive a reference to the root directory of the startup volume? BootDrive does not always contain the actual wdRefnum. Tech Note 77 contain code for finding out the wdRefnum of the System Folder. >5. How does one determine if the vRefNum returned by SFGetFile or > GetAppFiles is a volume reference number or a working directory reference > number? I think you can use PBGetCatInfo to find out. If you get the info for the vRefnum, you can check to see if the field ioDrDirID is 2, which indicates the root of a volume. >6. When an application starts up, are there any working directories? Yes, there will be at least a working directory for the folder containing the application. (I don't know what happens if the application is at the root.) >7. How does Launch know which volume to launch the application from? Launch uses the current volume. The code for ExitToShell does a SetVol back to BootDrive before launching the Finder. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
earleh@dartvax.UUCP (Earle R. Horton) (08/23/87)
In article <1560@apple.UUCP>, lsr@apple.UUCP (Larry Rosenstein) writes: > > The current volume (as returned by GetVol) will indicate the folder > containing the application. This will be a wdRefnum if the application is > inside a folder. ... > Launch uses the current volume. The code for ExitToShell does a SetVol > back to BootDrive before launching the Finder. > I believe there are problems with both of these statements. I base this claim on the assumption that SFGetFile will always show files in the default volume, and from observation of what folder I get from SFGetFile. If this assumption is false, then I may be wrong. I am using the term "volume" here to mean directory or folder, which appears to be the way Larry meant it. Sloppy, but you probably know what I mean. I have noticed that when you launch an application by double-clicking one of its documents, then do anything that uses Standard File, you usually get the folder the document is in, and not the folder the application is in. This indicates to me that either: a) All Mac applications use SetVol before opening documents (unlikely since not necessary) or b) The default volume gets changed to the one the document(s) were in when using the double-click-document method or c) The Standard File package maintains its own default volume (unlikely) I wrote an application which calls SFGetFile to find an application, then launches it. Named it "Finder" and put it in the system folder, booted from the disk. The folder shown first by SFGetFile is the root folder, and not the system folder. OK so far. However, when I launch an application on another volume (disk) and later quit back to my phony Finder, I get the folder containing the application that I launched, and not the one my bogus Finder is in. In this case, ExitToShell appears not to change the default volume or directory when launching the "Finder". Now, for the most interesting part, the undocumented feature of Launch! I claim that you can launch an application by: a) Calling SetVol to set the default volume to a directory the target application is NOT in, and on a different volume (disk). b) Calling Launch with a pathname that specifies the application you want. I also claim that the default volume remains the volume set in the first call to SetVol, before the launch. (This is with System 4.1, Finder 5.5., ROM version 117.) I have example code which demonstrates this, if anyone is interested. It's a program called RMaker. (I have a demo I wrote myself, too.) I don't recommend launching applications using pathnames, or even using any undocumented features, but it does appear to me that one cannot always depend on GetVol returning the same folder or WDRefNum that your application is in. It also appears that ExitToShell does not always set the default volume to the one the Finder is in, either. Please let me know if I am wrong. If I am, what makes SFGetFile look in what appears to be the wrong directory? (I know the Launch trick works, however, and I would not be surprised to find out that a large number of "batch" type programs use it.) In any case, the root question remains unsolved. Does anyone have code which will return, guaranteed, the WDRefNum of the folder which the current application is in? -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/23/87)
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.eduinfinity@well.UUCP (sunny at Infinity Software) (08/24/87)
Larry mentions that the System Folder will always be a local volume, probably/possibly very full if a local diskette drive. So, hey, what about MacSE's or MacII's as diskless workstations on Ethernet? Even if Apple insists you MUST buy a diskette drive, and boot from it to get going on the net, could you not switch to a System Folder, System and Finder resident on a network volume, toss the boot diskette in the desktop trashcan, and run totally diskless locally? Has Apple made no plans for this eventuality? Is Apple totally disregarding the possibility of head-to-head competition with Sun Microsystems for low-end network workstations? Or have I missed something of the context surrounding this discussion?
jww@sdcsvax.UCSD.EDU (Joel West) (08/24/87)
Diskless would be nice, but right now too much software assumes that
the System Folder is local, and it certainly cannot be shared.
You could have multiple remote system files on the server, but
right now the software also assumes one system file per disk, max.
A more likely scenario is to have the System/Finder in ROM and have
patches in a RAM disk, but this is years off.
--
Joel West (c/o UCSD)
Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083
{ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edu
or ihnp4!crash!palomar!joel joel@palomar.cts.comwoody@tybalt.caltech.edu (William Edward Woody) (08/24/87)
About changing the System Folder to something over the network: it can't
be done currently. You must run off a network using a floppy disk or
a hard disk local to the Mac containing the system folder.
(I had reasons of my own why I wanted to do this, but the software prevented
me from doing it.)
Maybe in later versions this will be possible, but can you imagine how
slow it would get waiting for the finder to come up, if the finder was
on a network volume, and the network was busy because 10 other people are
waiting for their finders to come up??? ;-)
- William Edward Woody Mac >> IBM && /|\ && ][n
_____UNTIL 1 SEPTEMBER 1987_____ ______AFTER 1 SEPTEMBER 1987_____
woody@tybalt.caltech.edu Net Address Unknown
woody@juliet.caltech.edu (I hope I get net access!)
1-54 Lloyd House 8038 N. Mariposa
Pasadena, CA 93710 Fresno, CA 93710
____________________________________________________________________________lsr@apple.UUCP (Larry Rosenstein) (08/24/87)
In article <6923@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes: > >I have noticed that when you launch an application by double-clicking >one of its documents, then do anything that uses Standard File, you >usually get the folder the document is in, and not the folder the >application is in. This indicates to me that either: Standard File maintains its own idea of the first folder to show when the dialog is displayed. This is documented (for HFS) in Inside Mac volume 4. There are 2 global variables that contain the (true) volume refnum and dirID of the folder that Std File will show first. I did an experiment with Finder 5.5 and System 4.1, and found that that when you open a document the Finder sets these variables itself to establish the folder that Std File will use initially. What I did was to double click on a MacWrite document the root of an HFS volume, with MacWrite in a folder on the same volume. I used Macsbug's SS command to break whenever location $398 (one of the Std File variables) changed. The variable changed twice during the launch. I think that the first time it was set to the folder containing MacWrite and the second time to the folder containing the document. I also checked to see if a call to PBHSetVol changed the Std File variables, and it did not. >I wrote an application which calls SFGetFile to find an application, >then launches it. Named it "Finder" and put it in the system folder, >booted from the disk. The folder shown first by SFGetFile is the root >folder, and not the system folder. OK so far. However, when I launch >an application on another volume (disk) and later quit back to my phony >Finder, I get the folder containing the application that I launched, and >not the one my bogus Finder is in. In this case, ExitToShell appears >not to change the default volume or directory when launching the "Finder". When you boot, the Std File variables are not set. The first time you bring up Std File, it notices this and defaults to the root of a volume (probably the current volume). When you launched the application you used Std File, which set the variables. When you brought up Std File again, it used the same variables and showed the same directory. You can't tell what the current volume is by looking at the folder that Std File shows you. The 2 things are completely different. ExitToShell does set the current folder to the one containing the Finder. (Look at locations $40F6EC-$40F6F2 of the Mac Plus ROM; this is a call to SetVol using BootDrive as the parameter.) >Now, for the most interesting part, the undocumented feature of Launch! >I claim that you can launch an application by: >...[using full pathnames] > Absolutely true. Full or partial pathnames are valid in the file system calls. The Launch code makes standard file system calls, so full pathnames are valid there as well. The Launch code does not change the current volume, this is done by the Finder. >I don't recommend launching applications using pathnames, or even using >any undocumented features, but it does appear to me that one cannot >always depend on GetVol returning the same folder or WDRefNum that your >application is in. It also appears that ExitToShell does not always >set the default volume to the one the Finder is in, either. I wouldn't recommend this either. You should always launch applications by setting the current volume, because some applications depend on this. Any shell-type application that does not set the current volume before a launch is wrong. >In any case, the root question remains unsolved. Does anyone have code >which will return, guaranteed, the WDRefNum of the folder which the >current application is in? I still argue that you should use the current volume in effect when the application is launched. Although there is nothing inherent in the Macintosh that makes this so, there is a very strong convention that makes this so. (The Finder and MPW Shell both do this, and some applications depend on this fact.) If you do not want to use this technique, I think you could call PBGetFCBInfo (see Inside Mac volume 4) and pass it the application's refnum (available from a global variable). I haven't tried this, but I think it should work based on what is written in Inside Mac. This call is NOT in the 64K ROMs, however, and the documentation says that the format of the file control blocks may change in the future. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
dorner@uxc.cso.uiuc.edu (08/26/87)
> About changing the System Folder to something over the network: it can't > be done currently. You must run off a network using a floppy disk or > a hard disk local to the Mac containing the system folder. > > - William Edward Woody Mac >> IBM && /|\ && ][n Yes, it can be done. I am doing it now with MacServe. I boot from a floppy (but enough brains to do boot and find a disk server could be put in a ROM a lot more easily than could the System/Finder), and then switch to a MacServe volume, and eject the floppy. Performance is fairly poor (like a 400K floppy) over Appletalk, but I don't think it would be bad over ethernet, and I can isolate myself from the delay by using a large disk cache (I'm currently using 192K). Performance is acceptable for most things. I wouldn't want to do program development this way, though... And, the MacServe volume I am using can't be shared. But there's no problem having multiple system files on one physical drive, as long as they are all on different partitions, or hidden from one another. Anyway, if Infosphere can do it, so can Apple. Whether or not it's worth it is up to them. Hard disks are so cheap nowadays that I don't imagine there are _many_ places where people can afford a network and not hard disks. Or, as the original note mentioned, a Mac II and not a hard disk. We, (the University of Illinois), however, are in that position due to the usual legislature/governor budget politicking... ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: {ihnp4,seismo}!uiucuxc!dorner IfUMust: (217) 333-3339