Closed Bug 101953 Opened 23 years ago Closed 11 years ago

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

Categories

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

x86
Windows 98
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: benc, Unassigned)

References

Details

(Keywords: helpwanted, meta)

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.
Priority: -- → P1
Removing bug 66194 from block list.

RFC 1738 compliant file URLs w/ UNCs do work for this reporter and the reporter 
of a dupe.
No longer blocks: 66194
ben, please isolate the problem more.  WorksForMe on win2k.  (file://///surge/dist).

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

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?
*** Bug 88293 has been marked as a duplicate of this bug. ***
Blocks: 88293
doug - what are the chances of this making the 0.9.4 branch?
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.
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.
Ben, I posted an messaged on the netlib newsgroup.  Maybe someone can help you
isolate the failures that have been reported.
Doug/Ben - Thanks for the update. Much appreciated.
Blocks: 54116
ben, could you isolate the failures.  assign bug to you.
Assignee: dougt → benc
"File | Open file..." looks like it works (bug 19174 and bug 28378). (mozilla 
0.9.4, Win98)
nsbranch- per Doug's comments of this having "zero" chances of making 094.
Keywords: nsbranchnsbranch-
Whiteboard: [ETA Zero chances of making 094, due to lack of repro test case)
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-
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?
No longer blocks: 8684, 88293, 99769
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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!

Blocks: 65298, 79419
Status: RESOLVED → REOPENED
Keywords: verifymensbeta1, qawanted
Resolution: WORKSFORME → ---
Summary: All UNC file access is broken (in some versions of Windows) → [meta] UNC file access is broken (in some versions of Windows)
Whiteboard: [ETA Zero chances of making 094, due to lack of repro test case)
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.
Assignee: benc → new-network-bugs
Status: REOPENED → NEW
another (bug 110832)
Blocks: 110832
+helpwanted -this is ready for engineering attention.
Keywords: helpwanted
Blocks: 133153
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.
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.
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...
gagan,doug: who should be looking at this bug?
-mozilla 1.0: come and gone.
Keywords: mozilla1.0
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"?
Blocks: 173219
file -> dougt
Assignee: new-network-bugs → dougt
Target Milestone: --- → Future
Blocks: 162025
Keywords: mozilla1.2
Depends on: 143567
No longer blocks: 162025
Depends on: 162025
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.
Blocks: 162025
No longer depends on: 162025
Blocks: 173343
As a tracking bug, this bug should be blocked by dependencies, not the other way
around.
Depends on: 109260
Depends on: 142196
Depends on: 142014
Depends on: 62888
Depends on: 139562
Depends on: 181861
Depends on: 193768
No longer depends on: 110832
No longer depends on: 101523
No longer depends on: 79419
Depends on: 173920
Depends on: 189875
Depends on: 137006
+topembed, -mozilla release keyword.
This bug is a tracking bug for problems with UNC (SMB) file systems.
removing topembed nomination as this is a meta bug, please nominate the
individual bugs as appropriate
Keywords: topembed
adt: ditto for nsbeta1.
Keywords: nsbeta1meta
Depends on: 123184
Depends on: 196487
Depends on: 229596
Depends on: 236902
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
(In reply to comment #31)
> Why not obey
> http://www.ietf.org/rfc/rfc1738.txt

Eh? Where does that use backslashes?
(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
5 probably come from file:/// plus the unc name (\\server\share\file) with backslashes converted to forward slashes
(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 ...
(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 ...
> 
(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.
(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
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.
mass reassigning to nobody.
Assignee: dougt → nobody
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...
Blocks: 139562
No longer depends on: 139562
No longer blocks: 139562
Depends on: 139562
Status: NEW → RESOLVED
Closed: 23 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.