A quick question about file URLs
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Nov 15 02:31:46 UTC 2005
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
========================================================================
===
More information about the Squeak-dev
mailing list
|