Ned Konz wrote:
> 
> On Thursday 09 October 2003 00:13, karl.ramberg at chello.se wrote:
> 
> > The use of FileDirectory default can cause some unexpexted behaviour on
> > MacOS classic. Changed to use FileDirectory new instead."!
> 
> We need to fix the FileDirectory logic for 'default', *not* change the API.
> 
> I have worked in this area some, but I don't have a MacOS Classic environment
> to test with. (Well, maybe I do on the ancient Powerbook; does the 9.2 that
> comes with Mac OS/X work OK if you boot from it?).
> 
> There has been long discussion (and many 'fixes') about the meaning and
> interpretation of relative paths on the Mac.
> 
> Please, let's get this logic working right rather than changing the usage!

Well, looked at this more carefully and found this
(Note all entries are directories.)
FileDirectory default fullNameFor: 'Video:Squeak3.6a:sm' =>
'Video:Squeak3.6a:sm' "works"
FileDirectory default fullNameFor: 'Video:Squeak3.6a' =>
'Video:Squeak3.6a:Video:Squeak3.6a' "error!!!"


FileDirectory activeDirectoryClass splitName: fileName to:
		[:filePath :localName |
			correctedLocalName _ localName isEmpty 
				ifFalse: [self checkName: localName fixErrors: true]
				ifTrue: [localName].
			prefix _ self fullPathFor: filePath].

First the fileName is split to filePath := Video and localName := Squeak3.6a
Then when prefix _ self fullPathFor: filePath is sent prefix will
resolve to 
'Video:Squeak3.6a:Video'

But if I send prefix _ self fullPathFor: 'Video:' it will answer 'Video:'

So should the fix be a MacFileDirectory>>splitName:to: that answers the 
filePath with delimiter when the path answers only the drive name ?

Anybody got a suggestion ?

Karl