Ok, the Mac Carbon VM still returns HFS+ file names, and of course  
HFS non-plus file names for OS-7.x because it shares the same code, and
after much pain provides the same behavior from macintosh os  7.5.5  
thru to os-x 10.4.3. There was some feeling that the transition from  
os-9 to unix path names was a bit abrupt and some care was taken to  
ensure the HFS support reminded.   I'l like to move towards using  
UTF-8 unix file paths however some work would be required to ensure  
HFS aliases are properly handled, Euros, greenbacks, loonies would of  
course help in this matter, and it may/will get forced by the  
migration to MacIntel because some of the HFS+ structures we use are  
going away.

As you noticed at startup time the DefaultDirectory is determined and  
the DirectoryClass based on asking the VM what OS and version it is,  
along with checking the length of the file name string to determine  
HFS, versus HFS+ support based on the boot volume. I'll note this  
cholce is poor because if you mount a HFS non-plus volume you could  
attempt to make a name > 31 characters which would fail, but the  
architecture in Squeak does not consider Volumes could have  
different  file system types on them.  However this all is run as  
part of the class startup logic to ensure the default directory and  
the class used for directory instances is correct.


Is it broken? er, well you could you know run the unix os-x vm and it  
will say you're on a unix machine and have true unix file names and  
then see what happens.  Some of the issue here is that based on the  
URI we need to understand if this is a relative or absolute URL since  
asking for text.txt in the current
directory is quite different than asking for /test.txt which is  
text.txt in the root directory.

It's a bit hard for me to test in a image on my desktop at the moment  
since in Sophie we are using the URI package
"A Uniform Resource Identifier (URI) is a compact string of  
characters for identifying an abstract or physical resource.
This implementation is based on http://www.ietf.org/rfc/rfc2396.txt."

and I'm not sure if it's mangled what the URL logic is doing, (well a  
quick check shows yes)
However for the record
'file:///test1.txt' asURI   retrieveContents
gives me a DNU on nil
and
'file://test1.txt' asURI   retrieveContents
returns the directory records content for root, *that is interesting*.

Sigh, lets find a 3.9 image.  (6696)
Both flavors get DNU
mm
contentStreamForURI:

Mmm this looks really familiar, in checking in 3.8 it's all  
different, I'm sure I fought with this stuff a couple of months ago.
Well I was up til 4AM last night so I can't quite remember the  
details, some more alert individual might comment now...


On 14-Nov-05, at 4:42 AM, Matthew S. Hamrick wrote:

> Hey all..
> a. Could someone be so kind as to create a file somewhere ( I'm  
> calling it 'test.txt' ) and see if the following code returns a  
> document...
>
>     ('file:///test.txt' asUrl) retrieveContents
>
> I don't have a non-Mac machine to test this on... Though I'm  
> thinking I should spend a little time recompiling the Squeak VM  
> against the MacOSX X11 libraries.
>
> b. Is the MacOS X version of FileDirectory really supposed to  
> return a MacHFSPlusDirectory? Shouldn't it return a UnixFileDirectory?
>
> c. How is the DefaultDirectory and DirectoryClass set in the image?  
> I chased this as far as looking at the  
> MacHFSPlusDirectory>>isActiveDirectoryClass and discovered that it  
> appears to be looking at how long a single file can be. This seems  
> odd as I would have expected other OSes (like Linux and XP to  
> exercise this code as well.)
>
> d. Is this supposed to be broken? I mean, is this a known problem  
> but it's behavior that's being maintained for reverse compatibility  
> or something?
>
> Any pointers would be appreciated.
> -Cheers,
> -Matt H.
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===