175991 - Chimera chokes on file:// URLs that include the startup disk volume name

Status: RESOLVED DUPLICATE of bug 175866

(Camino Graveyard :: General, defect)

Description

[Wincent Colaiuta]

Chimera can't handle file:// URLs that include the statup disk volume name.

For example, on my machine the startup disk is called "Jaguar". File URLs which
look like this...

file:///Jaguar/Users/wincent/web/public_html/TMPsnfvw4emlf.htm

...will cause Chimera to respond with a "not found" error, even if the file exists.

Mozilla 1.2b loads such URLs without a problem. Can we duplicate the Mozilla
behaviour?

Workarounds: Remove the Startup Disk volume name and one leading slash from the
URL and it will work. Eg. the following works:

file:///Users/wincent/web/TMPsnfvw4emlf.htm

Another work around is to created a soft symlink at the root of your startup
disk by doing something like "sudo ln -s / Jaguar" in the terminal. This creates
a link with the same name as the Startup Disk and points it at the root of the
volume.

The reason why a proper fix is desirable is that a number of Applications
produce file:// URLs which include the /StartupVolumeName at the beginning (for
example Dreamweaver). Apps like this will send these links to Chimera only to
have them fail to load up.

Comment 1

[Wincent Colaiuta]

Forgot to add, this is all on Chimera nightly 2002101804.

Comment 2

[Steve Smart]

This is because file:///StartupDiskName/ is not a valid location. The startup
disk is mounted at /, and additional volumes are mounted at /Volumes/DiskName.
Try doing a cd /StartupDiskName in the terminal and you will get
/StartupDiskName: No such file or directory. I'm guessing that Mozilla doesn't
talk directly to the OS when it does file URLs.

A nice solution for compatability would be to lookup the volume names and
automatically strip out any bogus leading '/StartupDiskName/...'s and convert
any '/OtherVolumeName/...' URLs to '/Volumes/OtherVolumeName...', assuming that
you don't have any folders named /StartupDiskName or /OtherVolumeName (so this
could just be checked if we get a not found from the original request).

Comment 3

[Greg K.]

Dup of bug 140606?

Comment 4

[Wincent Colaiuta]

Greg: not sure if it's a duplicate or not... that bug seems to be mostly
concerned with the handling of "localhost" in file:// URLs.

Steve: I know it's not a valid location in the filesystem. That's why I noted
the workaround of making an appropriate symlink at the root level of the Startup
Disk.

Comment 5

[Simon Fraser [no longer active]]

Dup of bug 175866.

*** This bug has been marked as a duplicate of 175866 ***