gregr@tekigm2.MEN.TEK.COM (Gregory S Rogers) (03/29/90)
This problem seems so simple, but I must have a basic misunderstanding, can anyone help? Using LSC 3.0 ... I call SFPutFile to enter a file name and select the folder (not the System Folder) to save into; SFPutFile(where, "\pPrompt", "\pText Box", NIL, &reply); I expect reply.vRefNum to return the Working Directory reference number for the folder chosen in the dialog. But after I call GetFInfo(); errnum = GetFInfo(reply.fName, reply.vRefNum, &theInfo); if a file of the name fName exists in the System Folder then errnum = noErr indicating the file already exists. But why is GetFInfo looking for fName in the System Folder??? Shouldn't it only look in the folder id'd by vRefNum??? If no file of name fName is in the System Folder, everything works fine and vRefNum is used to save the file to the correct and desired folder. I must be missing something very simple but I'm stumped. Thanks!
lsr@Apple.COM (Larry Rosenstein) (03/30/90)
There is something called the Poor Man's Search Path in the File Manager.
For compatibility reasons, the File Manager looks in the System Folder on
certain calls if it can't find the file in the requested directory. (See
Tech Notes 77 & 101.)
The behavior you see is the PMSP in action. A more serious case is where
you want to save a file and call Delete to make sure it doesn't already
exist. Delete also follows the PMSP and you could end up deleting a file
in the System Folder.
The best way to disable the effects of the PMSP is to use the low-level
File Manager calls (with explicit parameter blocks) and to always specify
a dirID in the call. (Of course this means making the Hxxx version of the
call.) If you specify an explicit dirID, then the File Manager only looks
in that directory. In MacApp there is a procedure FillInDirID that takes
a parameter block and fill in the dirID field. We used this to ensure that
the PMSP was never used.
There are other gotchas related to the PMSP. Tech Note 101 talks about
the problems with the Resource Manager using it in the call CreateResFile.
You can also have the opposite problem. Suppose you wanted to locate your
program's preferences file in the System Folder. You might just try
opening it in the application's directory, and let the PMSP find it in the
System Folder.
This will work provided your application is on the same volume as the
System Folder. The PMSP doesn't check volumes other than the one you
specify in the File Manager call. If the program is on a different volume
the PMSP won't be used. (If the volume has a blessed folder it will be
searched instead.)
Larry Rosenstein, Apple Computer, Inc.
Object Specialist
Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1chewy@apple.com (Paul Snively) (03/30/90)
In article <8751@tekigm2.MEN.TEK.COM> gregr@tekigm2.MEN.TEK.COM (Gregory S Rogers) writes: [Stuff about why GetFInfo on a WDRefNum doesn't fail if a file with the same name happens to live in the System Folder.] The good news is that your question isn't as simple as you think, i.e. it's not a "stupid" question at all. The bad news is that you're being bitten by a little-known and even less understood feature of HFS called the Poor Man's Search Path (PMSP). Somewhere down in low RAM, there is a list of vRefNums and dirIDs. Whenever most of the file manager routines are called (including GetFInfo), the file manager will check the first vRefNum/dirID pair in the list. If the file is there, you'll get that info. If not, it tries the next pair, etc. until it either succeeds or runs out of pairs (resulting in a fnfErr). Under normal conditions, there are only two pairs in the list: the first is whatever was specified in the call, and the second is the vRefNum/dirID of the blessed folder. So if the file isn't in the place you specified, but is in the blessed folder, sure enough, GetFInfo will tell you about it. Several years ago, I wrote a DA/INIT combination called "Set Paths" that gives you explicit control over the PMSP list; it allows you to specify up to five folders to be searched. It's easily the ugliest hack that I've ever written. There is at least one Tech Note on this subject. Unfortunately I do not have my Tech Notes in front of me, so I cannot point you to the exact one. If you have the Tech Note index, I'd recommend looking up "HFS," or if you're lucky, "PMSP" will be in the index as well. There are a couple of workarounds: after calls like GetFInfo, compare the vRefNum and dirID against what you passed (breaking down the WDRefNum by using GetWDInfo, if necessary) and, if they don't match, take the results with a grain of salt (or be really picky and compare the results against whatever SysEnvirons tells you the WDRefNum of the blessed folder is). The overhead for this might be unacceptable. Another workaround is to find the appropriate Tech Note, which documents a one-time "don't use the PMSP" capability. You can also just plain turn the PMSP off (don't forget to turn it back on again after you're done, please). Hope this helps, at least a little! __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. 1st Choice: Paul_Snively.DTS@qm.gateway.apple.com 2nd Choice: CHEWBACCA@applelink.apple.com Last Choice: chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________