[BUG][Mac] FileDirectory>fullNameFor: seems daft

Tim Rowledge tim at sumeru.stanford.edu
Sat Dec 8 05:35:56 UTC 2001


This bit me at 2am this morning preparing for a 9am demo (of course!) as
part of moving a swiki appliation from linux to Mac. Of course it seems
obvious on hindsight that ther will be some interesting problems when
mixig URLs and filenames, but it's just so easy to drift into
that comfortable place where filenames and URLs are essentially the
same.

I managed to quickly hack in a conversion method that fixed the path
separator problem, but what bit me most oddly was a strangeness in the
behaviour of FileDirectory>directoryNamed:

It appears to me to be the fault of FileDirectory>fullNameFor: as
implemented for the Mac. In fact, Mac uses the default version instead
of any special code. Acorn, DOS and unix all override and do something
more nearly sensible seeming.

The problem is that the test is simply 'is the additional path empty'
and is so then the directory path is returned, if not then the
_additional path_ is returned. Thus
	(FileDirectory on: 'Wibbler:Squeak:blah') fullNameFor: 'files:testing'
will return 'FileDirectory on: 'files:testing'' instead of what one
would expect (and get on Acorn, DOS, unix) 'FileDirectory on:
'Wibbler:Squeak:blah:files:testing' !

So far as I can work out most (ab)uses of this code work ok on Macs
because they refer to subdirectories of the working directory and thus
'files:testing' is ok. Unfortunately as soon as your base directory is
somewhere else you are in deep do-do.

My temporary fix was to check to see if the additional path string
started with the machines disc name ( hard coded in my case - hey it was
2:30 am by this time!) and if so assume a properly rooted path was
present. Nothing seems to have broken due to this, but clearly a cleaner
solution is needed. Then again, the file naming and handling code has
need cleaning for ages anyway.

 tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: UBC: Use Bad Chip





More information about the Squeak-dev mailing list