289269 - If we type any string along with file:// it shows Local File System.

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Narasimha]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050406 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050406 Firefox/1.0

Description of Problem:
type file://xyz (or anything after file://) in URL bar, local file 
system
will be listed with the typed string. This is with Mozilla 1.6 also.



Reproducible: Always




OK, so the bug, such as it is, is that if you enter "file://foo" where
"file:///", except that it's described as "file://foo" rather than
"file:///".  NB: this is true regardless of whether /foo exists, since
one is supposed to browse that as "file:///foo" (3 slashes).

Comment 1

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050407
Firefox/1.0+

I am not sure that I understand what you wrote. Do you mean:

file:///root/path/file      maps to     /root/path/file      (right)
file://path/file            maps to     path/file            (wrong)

If so, what do you want?

(FWIW, I find that file:// in the URL gives me "The file / cannot be found")

Comment 2

[Chris Applegate]

On Linux, it works just the way the reporter said. Enter file://xyz (xyz may
represent any string that is *not* a file[1]) and the local filesystem is
opened. To wit,

1. file:/xyz spawns a "file not found" alert
2. file://xyz displays / and displays an "Index of file://xyz/" header
3. file:///xyz spawns a "file not found" alert

One and three seem to be the correct behavior. Two seems incorrect.

Trying the same thing with some file that does exist, like /bin:

4. file:/bin maps to file:///bin and displays /bin
5. file://bin displays the contents of / (but says //bin in the header)
6. file:///bin correctly displays /bin

If you enter a file URL without any appended string, whether you use one, two,
or three slashes, then you are immediately sent to file:/// and the contents of
/ is displayed. I don't know if this is correct or not, but it's nicely consistent.

[1] Using the Unix "everything is a file" meme.

Comment 3

[Ben Fowler]

Your case 2. (file://xyz) gives me "The file / cannot be found. Please 
check the name and try again."

May be it is platform specific.

Comment 4

[Chris Applegate]

I looked at some other file: bugs and it does seem to be platform specific. A
quick look at RFC 1630 shows that file URLs have to have a host. So,

1. file:/xyz should fail due to being a bad URL, unless Mozilla is nice and adds
the missing slash(es). Case 4 above suggests that the latter happens.
2. file://xyz should fail unless the hostname is actually xyz.
3. file:///xyz should fail because /xyz doesn't exist.

At no place, AFAICT, should the / directory be displayed. The second set of
cases, with extant resources on localhost, has its own problems. And, once those
are fixed, the xyz and /bin cases have to be made consistent with each other.

Comment 5

[Ben Fowler]

(In reply to comment #4)
> A quick look at RFC 1630 shows that file URLs have to have a host. So,
> 
> 1. file:/xyz should fail due to being a bad URL, unless Mozilla is nice 
>     and adds the missing slash(es). Case 4 above suggests that the latter 
>     happens.
> 2. file://xyz should fail unless the hostname is actually xyz.

On Mac OS, even adding my computer's hostname, the file:// url in your
case 2. does not work. 

Having said that, you may not have stated the "unless" part of case 2 correctly,
because, the file:// url 'file://tit002.local./Users/bfowler/' with a hostname
and local path does work, as does 'file://tit002.local./Users/', and
'file://tit002.local./bin/' but 'file://tit002.local./' nor a version with 
no slash does not. Also, 'file://tit002.local./xyz/' produces the expected
error dialogue "file /xyx/ does not exist ...". I would think (but I am not 
certain) that Mozilla's behaviour on the Mac is both correct (within 
specification) and strictly correct (no unspecified or undefined behaviour).

It is slightly surprising that it does not also work on linux, as I would 
have thought that it would be a fairly mechanical process to pass the work
off file system.

Comment 6

[Angelo]

this should go to Core -> Networking: File

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Chris]

This is still a problem for me.  I use file: links to a network server (on http:
pages) as part of our local security checks, so I can only use IE at present.

I am a Windows user (obviously) and have just done dome simple checked on ff1.5
using a file called grid.gif on a remote server called oldathlon.  

1) file: links to the remote server do not work (see ffbuga.gif) but they do to
the local server

2) The remote .gif dropped onto the firefox window is displayed, and can be
bookmarked and retrieved later (the bookmark reference starts
file://///oldathlon).  The icon can be grabbed from the address field and
dropped onto the local desktop as a shortcut but it gets a reference starting
file://oldathlon (see ffbugb.gif)

3) The shortcut will open a new Firefox window (if ff is the default browser)
and load the image (presumably from the remote server), but with an error
message that says it can't find something it needs (see ffbugc.gif)

I think there's enough here without me going on to test the stage I really need,
which is the file: link on an http: page.

Chris Cowsley

Comment 9

[Chris]

Attachment: zipped set of three gif screen shots

file: bugs - ff beta 1 on W98SE

Comment 10

[Samuel Sidler (old account; do not CC)]

Using Firefox 2.0.0.3 on Mac OS X 10.4.9, Windows XP SP2, and Ubuntu 6.10, I can't reproduce this bug. When I type in "file://foo" (no quotes), I get a "File note found" error message.

I believe our error message handling has changed this since a year and a half ago. Am I misunderstanding? Narasimha or Chris, can you please update me on the status of this bug?

Comment 11

[Chris]

I agree with you, and the local-remote server issue is now sorted.   There will still be problems with IE sites exploiting IE's syntactical generosity but that is a different discussion.

Sadly I am not able to validate with W98 at present.

Comment 12

[Chris]

PS  I need five forward slashes to get the reference to work for FireFox.   IE works with two, four or five slashes.   How well known is the five-slash syntax?

Comment 13

[Samuel Sidler (old account; do not CC)]

Based on comment 11, closing this as "works for me". If you have further questions, feel free to ask in the newsgroups (they're available through Google Groups).