[Mac] VM - Can Someone Please Explain this Code?
John M McIntosh
johnmci at smalltalkconsulting.com
Sat Jan 6 07:57:34 UTC 2001
>In sqMacDirectory.c, there is a function (and comment):
> (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
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
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
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
More information about the Squeak-dev