>G'Day,
>
>In sqMacDirectory.c, there is a function (and comment):
>
>int lookupPath
>   (char *pathString, int pathStringLength, int *refNumPtr, int *volNumPtr)
>     /* Resolve the given path and return the resulting folder or volume
>        reference number in *refNumPtr. Return false if the path is bad. */
>
>What the code does is to walk the path hierarchy checking that the directory
>exists at each level.
>
>Can someone please tell me why it needs to do this?  After all, can't you
>just throw the path at PBGetCatInfoSync() and it will tell you if it was
>valid?

In general since the File I/O part of the mac VM was written a long 
time ago (decades in internet years) it is a mixture of old/new mac 
OS calls, if you look at the VM what you will observe is usage of API 
dating from 1984, one or two of these I had to replace because of 
Carbon, upto the APIs introduced in the early 90s. Apple of course 
evolved the file API's greatly over the years just to complicate 
matters. Because of this and the fact that this support code is 
boring (so to speak) once it works there isn't incentive to go back 
and change things, since, well things work. The fact it's broken in 
OSX can be viewed as a bug on Apple's part but seriously I doubt 
Apple is going to fix it so we must fix Squeak.

To complicate things Squeak deals with files/directories using the 
full path name. Which then we need to map into something the mac api 
supports. In this case we take the full path and return the name of 
the directory/file and the directory id and volume id so you can use 
it for the delete call which needs the three identifiers, mind I 
suspect the full path name might work for the delete call.

As you point out PBGetCatInfoSync would do the trick and avoid all 
that other code that walks the directory tree ensuring the path is 
correct.

I'm not been tempted to rewrite the existing macintosh code in the 
file area since it works, but as you've found out I was also 
frustrated to see a number of issues arise with Mac OS-X carbon port.

The proper way to fix this would be to call FSMakeFSSpec function or 
the PBMakeFSSpec function to create FSSpec records at the point where 
we need to convert a Squeak path to a directory or file into 
something that is used to manipulate the item in question. This would 
be a good thing! Since in numerous places we convert a path name to a 
number of identifiers to make the api call and we mix generations of 
api. So just code up one routine that takes a path, and returns the 
spec and if the object already exists and the error state, then 
change all the api's to use fsspec logic.

If you want to spend some time redoing this then please do an SUnits 
for file/directory manipulation to ensure we've proper behavior would 
be great and a help to ensure we've not broken anything, also a great 
help for porters. Ensuring this all works with multiple mac volumes 
is an important test point.

Oh another problem area is at startup time when it sorts out the 
image and changes names and locations. Again there are some search 
path issues and assumptions being made about where the image is in 
relationship to the VM, and we toss the calculated path name to the 
Vm and image file about.

Also see http://developer.apple.com/techpubs/mac/Files/Files-88.html and
http://developer.apple.com/technotes/fl/fl_510.html


PS I did notice in some places we call PBGetCatInfo then create a 
fsspec, which is redundant for the purpose of doing the PBGetCatInfo 
call which is being  used to see if the file/directory exists, since 
the create fsspec call will tell us if the file/directory exists.


-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================