Hi Matthew!

Hehe, file urls... hell on earth. First off - Michael Rueger and I may
disagree BUT:

AFAIK the "truth" for the "file" scheme is still RFC1738, see:
	http://www.iana.org/assignments/uri-schemes

Mozilla's tests which I based the FileUrl on (when I rewrote it a long
time ago):
	http://www.mozilla.org/quality/networking/testing/filetests.html

Ok, and oh - read the FileUrl class comment and the UrlTest class too.
:)

One thing that Michael and I disagree on (IIRC) is that my stance is
that the path in a FileUrl is always absolute. Michael has implemented
the URI package based on 2396 IIRC, but IMHO (and I may be wrong) 2396
is not the authoritative RFC for file URLs. I assume he might now
correct me on that point.

Now, for your specific issue:

"Matthew S. Hamrick" <mhamrick at cryptonomicon.net> wrote:
[SNIP]
> Now if I'm working with a local file and I do the following...
> 
>      ( 'file:///Users/mhamrick/sites/cryptonomicon.net/index.html'  
> asUrl ) retrieveContents ,
> 
> I get an UndefinedObject back. I've traced the problem to the line:
> 
>      FileDirectory default

Ok, where? :)

> which on my MacOS X machine returns an object of class  
> MacHFSPlusDirectory. Looking further in the code, I find places where  
> I believe some code wants to receive pathnames with slashes '/',  
> while other places the system seems to think that the classic ':'  
> colon is the file delimiter to use. I believe this confusion is  
> causing the problem.

Could be - can you be more specific?

> The Questions...
> 
> 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

Well, right now I am on a win-box, but this works:

	'file:///c%3A/test.txt' asUrl retrieveContents

and this *should* work but doesn't (!!), see below for a first analysis.

	'file:///test.txt' asUrl retrieveContents

Note that the path following 'file:///' is interpreted as *absolute*.

> 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.)

John is the authority there.

Hmmm, sigh... ok, here comes my analysis (and this may not be related to
your specific issue - but it sure is a problem anyway):

- In 3.7 'file:///test.txt' works fine (giving me 'c:\test.txt' on
win32), the code that makes the difference is FileUrl>>pathForFile which
Andreas changed in cs6360 - not sure what the issue was, but I recall he
was fixing something. As it stands now it does not work correctly IMHO.

The difference is that in 3.7 a path 'test.txt' is transformed into an
absolute path which then is used to successfully open the file. In 3.8
it is not.

I haven't looked deep enough to understand why Andreas did his changes,
perhaps it was just a refactoring that accidentally modified behavior.
Or it was intentional. :)

Given that I am now team leader for the Network Steward Team I intend to
figure out how it *should be* - at leat on the FileUrl side of the
equation. :)

regards, Göran