101953 - [meta] UNC file access is broken (in some versions of Windows)

Status: RESOLVED WORKSFORME

(Core :: Networking: File, defect, P1)

Description

[benc]

For the last few months, I have noticed bugs that accessing shared disk space in 
Windows (sometimes called SMB servers or UNC paths, if I have this right...) is 
not working.

I've reviewed about 80% of the bugs in "Networking:File", and I'm not seeing a 
bug that describes this accurately, so I'm creating it now.

I have seen complaints of the following:

Launching from shared disk space causes app to die.
file: URLs that use UNCs fail.
Importing bookmarks that are on UNC space fail.
Cache on UNC space fails.
Profiles on UNC space fails.

I'll try to link the bugs in an mark them as depends.

+nsenterprise, nsbranch:

even though it does not have anything yet b/c I'd like to see Netscape 
management poll their staff to get all the bugs and assess whether this needs to 
be fixed for "whatever we ship next." This is late in the game, but with an easy 
fix, and some luck...

NOTE: Do not mark your bug a duplicate of this bug, mark it a depends, and leave 
it in your component.

Thanks to "timeless" for making some points about why this needs to be 
addressed.

Comment 1

[benc]

Removing bug 66194 from block list.

RFC 1738 compliant file URLs w/ UNCs do work for this reporter and the reporter 
of a dupe.

Comment 2

[Doug Turner (:dougt)]

ben, please isolate the problem more.  WorksForMe on win2k.  (file://///surge/dist).

Also, there is a workaround for this problem.  Map the remote server.  

Comment 3

[benc]

What we really need is updates on the bugs I've linked in here.

dougt: sorry, not much of a windows user. what does "Map the remote server" mean?

Comment 4

[David Illsley]

*** Bug 88293 has been marked as a duplicate of this bug. ***

Comment 5

[Jaime Rodriguez, Jr.]

doug - what are the chances of this making the 0.9.4 branch?

Comment 6

[Doug Turner (:dougt)]

Jaime -
since ben has no reproducible test case nor can identify systems which have this
problem, I would say zero.

Ben - 
deterimine what URL cause problems.
double check how many slashes are in the URL after the scheme.  There should be 5.
isolate the problem - what veresion(s) of windows does this problem occur on.

Comment 7

[benc]

Jamie:

I'm saying we need to get everyone in QA to check off their bugs in the block
list. I already started to verify a couple of the related cases, so lets leave
dougt out it until there is code for him hack.

You should probably get someone to install on a shared drive and dogfood for a
day...

Doug: 

I'll use mapping as a workaround if this ends up being relnoted.

Comment 8

[Doug Turner (:dougt)]

Ben, I posted an messaged on the netlib newsgroup.  Maybe someone can help you
isolate the failures that have been reported.

Comment 9

[Jaime Rodriguez, Jr.]

Doug/Ben - Thanks for the update. Much appreciated.

Comment 10

[Doug Turner (:dougt)]

ben, could you isolate the failures.  assign bug to you.

Comment 11

[benc]

"File | Open file..." looks like it works (bug 19174 and bug 28378). (mozilla 
0.9.4, Win98)

Comment 12

[Jaime Rodriguez, Jr.]

nsbranch- per Doug's comments of this having "zero" chances of making 094.

Comment 13

[Hong Kwon]

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Comment 14

[benc]

RESOLVED/WFM: +verifyme
Bugs 8684, 88293, and 99769 are working now.
Also 55591 is working to my satisfaction now.
I've removed these bugs from the block field, I've asked for updates in the bugs
of other components, so if something does not work, they will have to figure it out.

Timeless: you started this, you want to verify?

Comment 15

[benc]

REOPEN:
Still problems with UNCs in several bugs.
added 65298,79419.

cleaing whiteboard.
+nsbeta, qawanted - somebody (like the ADT) go ping the QA owners of the bugs in
the "blocked" field and find out if this is still broken!

Comment 16

[benc]

Furthermore, assigning to default owner of Networking component b/c dougt didn't
want this, and I certainly am not capable of fixing this if there is a
networking problem.

Comment 17

[benc]

another (bug 110832)

Comment 18

[benc]

+helpwanted -this is ready for engineering attention.

Comment 19

[Ben Hutchings]

Surely URLs for UNC paths should be in the form <file://hostname/sharename/> (1)
not <file://///hostname/sharename/> (2)?  This is what RFC 1738 seems to suggest
(and it's what we use at Roundpoint).

Here's a quick survey of the behaviour of other browsers:

Internet Explorer 5.5: treats both (1) and (2) as a UNC path
Lynx 2.8: treats (1) like an ftp URL; treats (2) as a UNC path
Netscape 4.7: treats (1) like an ftp URL; rejects (2)
Opera 5: treats (1) as a UNC path; rejects (2)

I would strongly favour accepting both (1) and (2) under Windows, since users of
other browsers may expect to be able to use either.  The FTP interpretation
doesn't seem at all useful, given that the ftp scheme provides an unambiguous
means to refer to resources accessible by FTP.

Comment 20

[benc]

The file:// URL w/ UNC syntax debate occurs in bug 66194. Please read that bug
and comment (if necessary) over there.

The hostname you are thinking of is "name of the system your browser runs on",
not "server name of my file on the LAN". Bug 70871 discusses the correct usage
(or uselessness) of this field.

Comment 21

[benc]

neeti (and ADT people too). The number of bugs reporting this type of problem is
very long. You really should lean on the QA owners of the bug to update their
status...

Comment 22

[neeti]

gagan,doug: who should be looking at this bug?

Comment 23

[benc]

-mozilla 1.0: come and gone.

Comment 24

[benc]

neeti: QA and engineering should all be looking at any features that access
local filespace.

I think everyone who matters organizationally is cc'd on this bug, its just a
matter of them getting the individual people who need to look at this motivated.

Networking: file itself seems to do all of this correctly, based on the testing
I have done. 

Perhaps we should move this bug to the "Tracking component"?

Comment 25

[Doug Turner (:dougt)]

file -> dougt

Comment 26

[benc]

UNC's work in some areas, but not in others. The situation for W2K environments
where they use shared directories is really bad. Take a look at bug 162025.

Is there going to be any push by QA and engineering to triage these UNC bugs. 

Doug, it sounds like there are two file i/o interfaces, one is good and one is
bad. Is there anything you can do to see if people are using something that
doesn't support UNC's?

I can try to provide test environments for internal QA, but they ultimately need
to confirm and reproduce these bugs so engineers have something to look at.

Comment 27

[Andrew Hagen]

As a tracking bug, this bug should be blocked by dependencies, not the other way
around.

Comment 28

[benc]

+topembed, -mozilla release keyword.
This bug is a tracking bug for problems with UNC (SMB) file systems.

Comment 29

[saari (gone)]

removing topembed nomination as this is a meta bug, please nominate the
individual bugs as appropriate

Comment 30

[Samir Gehani]

adt: ditto for nsbeta1.

Comment 31

[Adrian Aichner]

file:\\host\file\path
used to work fine upto at least Fx 1.0.7
and I have put a lot of such links into a wiki at work, since this was syntax working in IE (officially supported at my workplace) and Fx (the browser I muchly prefer over the incumbent).

This no longer works in Fx 1.5.0.1 and 1.5.0.2.

Why not obey
http://www.ietf.org/rfc/rfc1738.txt

Adrian

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #31)
> Why not obey
> http://www.ietf.org/rfc/rfc1738.txt

Eh? Where does that use backslashes?

Comment 33

[Adrian Aichner]

(In reply to comment #32)
> (In reply to comment #31)
> > Why not obey
> > http://www.ietf.org/rfc/rfc1738.txt
> 
> Eh? Where does that use backslashes?
> 

Thanks for the followup!

I was bringing up http://www.ietf.org/rfc/rfc1738.txt as the best standard I could find against the file:///// syntax.

What's the rational for the five slashes and is there any standard or proposal in its defense?

I could see how I would convert my file:\\ links once to some universally accepted standard file scheme working in both Fx and IE.

Please advise!
Adrian

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

5 probably come from file:/// plus the unc name (\\server\share\file) with backslashes converted to forward slashes

Comment 35

[Andreas Otte]

(In reply to comment #34)
> 5 probably come from file:/// plus the unc name (\\server\share\file) with
> backslashes converted to forward slashes

Exactly. The file protocol is by defintion a local protocol, the host part in the url is unnecessary. It can eiter be localhost or the hostname of the local machine, never something else and because of that it is most of the time omitted, hence file:///something urls. All the UNC stuff has to take place in the path/filename component with the remote machine markimg the first part. 

If we get an file://host/path url we have to fix it in some way:

- the host is local, we can ommit it
- host is part of the path, move it there (for example if it looks like c: on windows)
- the host looks like a known share, trigger SMB protocol in the OS if available, but what do you do if (for example) on a unix-like system there is also a directory named like the share? Which one to use?
- ...

The list goes on and I'm not sure how much of this possible fixup we actually do. Some of it depens on the OS and happens or has to happen in the OS-specific conversion stuff in URLHelper ...

Comment 36

[Adrian Aichner]

(In reply to comment #35)
> (In reply to comment #34)
> > 5 probably come from file:/// plus the unc name (\\server\share\file) with
> > backslashes converted to forward slashes
> 
> Exactly. The file protocol is by defintion a local protocol, the host part in
> the url is unnecessary. It can eiter be localhost or the hostname of the local

By which definition?

Can you cite your sources for this claim?

What about
http://www.ietf.org/rfc/rfc1738.txt
why is it not relevant?

It clearly states support for <host> under 3.10.

What standards is Firefox implemented against, I wonder.

Adrian

> machine, never something else and because of that it is most of the time
> omitted, hence file:///something urls. All the UNC stuff has to take place in
> the path/filename component with the remote machine markimg the first part. 
> 
> If we get an file://host/path url we have to fix it in some way:
> 
> - the host is local, we can ommit it
> - host is part of the path, move it there (for example if it looks like c: on
> windows)
> - the host looks like a known share, trigger SMB protocol in the OS if
> available, but what do you do if (for example) on a unix-like system there is
> also a directory named like the share? Which one to use?
> - ...
> 
> The list goes on and I'm not sure how much of this possible fixup we actually
> do. Some of it depens on the OS and happens or has to happen in the OS-specific
> conversion stuff in URLHelper ...
> 

Comment 37

[Andreas Otte]

(In reply to comment #36)
in
> > the url is unnecessary. It can eiter be localhost or the hostname of the local
> 
> By which definition?
> 
> Can you cite your sources for this claim?
> 
> What about
> http://www.ietf.org/rfc/rfc1738.txt
> why is it not relevant?
> 
> It clearly states support for <host> under 3.10.
> 
> What standards is Firefox implemented against, I wonder.
> 

It is implemented against 1738, it is a bit old. The URLParser mainly against RFC 2396. I guess it is all opinion:

See 3.10 from RFC 1738:

   The file URL scheme is used to designate files accessible on a
   particular host computer. This scheme, unlike most other URL schemes,
   does not designate a resource that is universally accessible over the
=> ^^^^^^^^^^^^^^^^^^^^^^^

   Internet.

   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

   ...

   As a special case, <host> can be the string "localhost" or the empty
   string; this is interpreted as `the machine from which the URL is
   being interpreted'.

In my opinion this is not a special case but the only case. The reason follows in the next sentence in the RFC:

   The file URL scheme is unusual in that it does not specify an
   Internet protocol or access method for such files; as such, its
   utility in network protocols between hosts is limited.

In my Opinion that designates a local protocol. It does not define any protocol to adress a file on a remote computer. That is *the* big difference to form example http or ftp. Nothing except localhost or the current host makes sense as host-component when there is no protocol to acces something remotely. Everything depends on the underlying OS and the kind of URLFixup we try.

Comment 38

[Adrian Aichner]

(In reply to comment #37)
> (In reply to comment #36)
> in
> > > the url is unnecessary. It can eiter be localhost or the hostname of the local
> > 
> > By which definition?
> > 
> > Can you cite your sources for this claim?
> > 
> > What about
> > http://www.ietf.org/rfc/rfc1738.txt
> > why is it not relevant?
> > 
> > It clearly states support for <host> under 3.10.
> > 
> > What standards is Firefox implemented against, I wonder.
> > 
> 
> It is implemented against 1738, it is a bit old. The URLParser mainly against
> RFC 2396. I guess it is all opinion:
> 
> See 3.10 from RFC 1738:
> 
>    The file URL scheme is used to designate files accessible on a
>    particular host computer. This scheme, unlike most other URL schemes,
>    does not designate a resource that is universally accessible over the
> => ^^^^^^^^^^^^^^^^^^^^^^^
> 
>    Internet.
> 
>    A file URL takes the form:
> 
>        file://<host>/<path>
> 
>    where <host> is the fully qualified domain name of the system on
>    which the <path> is accessible, and <path> is a hierarchical
>    directory path of the form <directory>/<directory>/.../<name>.
> 
>    ...
> 
>    As a special case, <host> can be the string "localhost" or the empty
>    string; this is interpreted as `the machine from which the URL is
>    being interpreted'.
> 
> In my opinion this is not a special case but the only case. The reason follows
> in the next sentence in the RFC:
> 
>    The file URL scheme is unusual in that it does not specify an
>    Internet protocol or access method for such files; as such, its
>    utility in network protocols between hosts is limited.
> 
> In my Opinion that designates a local protocol. It does not define any protocol
> to adress a file on a remote computer. That is *the* big difference to form
> example http or ftp. Nothing except localhost or the current host makes sense
> as host-component when there is no protocol to acces something remotely.
> Everything depends on the underlying OS and the kind of URLFixup we try.
> 

Thanks for explaining your reasoning and confirming RFC 1738 is applicable.

I do understand the resource is not *universally* available, but I don't think this requires to go to extremes and limit it to entirely local resources, and not to support the host component at all.

I hope a future Fx release will succeed in accessing file://host/path URLs so that I can once again ditch IE.

Adrian

Comment 39

[Andreas Otte]

It was this "limited" for years (or forever). What changed are different approaches and levels of fixup. Note that it is not possible to decide sometimes if file://somewhere/something was a typo and meant file:///something or really "use some OS functrion to access something with an unknown protocol frome somewhere". Sometimes fixing the fixup breaks another usage case. Use file://///somwhere/something and everything is clear.

Comment 40

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 41

[Leon Stringer]

As I see it, there are three good reasons for adopting the "file://server/share/file" to access UNC resources (as opposed to file://///") on Windows:
 - It's recommended for the the platform
 - It's a clearly defined namespace
 - It's understood by most other browsers (notably IE, Opera and Chrome)

The reason not to is that it would be a platform-dependent assumption that isn't portable. "file:" is always going to be a kludge but surely it's down to mapping it to the underlying filesystem and in this case it would be to adhere to the recommendations in http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx.

Personally I find it frustrating that in the cases when it's useful to use file: to access UNC resources, it's understood by everything but Firefox...