\\natalie - doesn't work \\natalie\incoming - work NetBIOS network
Reporter are these local files or remote files? What build are you using? What platform are the files being hosted on etc?
Platform W2K. Buils 2000121204 Mozilla doesn't show list of shared folders at Linux, Win9x, WinNT. If I add shared folder name to host name(e.g. \\natalie\incoming) its contains are showed correctly.
When attempting to list the shares available via NT file sharing (this will work on win9x or greater) mozilla freezes. If you have NT you can browse to \\<your machine name> or if you have 9x you will have to enable file sharing in your network properties. (Build 2001011004 WinNT) It is debatable as to whether we should be able to view NT file shares or not because 4.x never did. I recommend marking this bug wontfix or invalid because Mac and Linux will not be able to view these files without adding extensive code to the netwerk bits. Recommended behavior would be displaying an error on a \\servername\ style URI. Confirming
Open Networking bugs, qa=tever -> qa to me.
-> file. Similar to several other bugs.
Where are you entering this? Is this a HREF link or is this in the location bar? If I understand what you are asking for, what probably neds to happen is that the UI you enter the path needs to convert to a file URL.
I entered this lopcation bar "\\server\incoming" and "file://///server/incoming" works fine, but both "file://///server" and "\\server" don't work
Okay. This needs an additional round of definition.
So this is a "top" level of server bug, subdirectoris work fine, right? Please let me know if the new summary is accurate. Also, does this happen in other platforms?
UPDATE: Commercial trunk 2001100403 Same as reporters behavior. + arch: This does not work in Comm 4 either, so I am not sure if this is desired behavior.
*** Bug 107540 has been marked as a duplicate of this bug. ***
"\\natalie" is not a valid UNC path and does not represent a shared drive. In the UNC path "\\natalie\incoming", "incoming" is a share name, not a sub-directory name. You can confirm this by typing "dir \\natalie" (substituting a locally valid machine name) at a command prompt; it will fail. Under Windows 2000, the error message is "The filename, directory name, or volume label syntax is incorrect." Windows Explorer seems to handle this as a special case, and that's what Prisacari seems to want. That's surely a feature request, not a bug report.
I am unable to use file URLs with UNC paths which are in links. For example, I have a special page with a bunch of links to internal locations, things like file://server/share When I click on one of these links, nothing happens. It works in IE.
Please look at bug 122022.
moving neeti's futured bugs for triaging.
-> default owner
This would be an enhancement, not a bug. Like comment 3, I recommend wontfix.
RESOLVED/WONTFIX: You can't have a SERVER w/o a share. The suggested UNC is invalid. from a Microsoft site... A Universal Naming Convention (UNC) name identifies the networked file. The UNC name consists of a server name and a share name, such as \\SERVER\SHARE. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmgch06.asp Would someone VERIFY/WTF if they agree?
I agree with comment 3 and with Ben. Resolving as wontfix.
Maybe bad summary has confused you, but originally this bug was about Mozilla isn't showing list of shares. It is not about Mozilla's support of UNC.
I found an IETF draft document that suggests: //servername/ and smb://servername/sharename That draft is at: http://www.globecom.net/ietf/draft/draft-crhertel-smb-url-02.html Currently, Mozilla does not support the SMB protocol in URIs. Listing shares appears to be a small need that would require great effort to implement. It's not clear why we need a web browser to list SMB shares.
*** Bug 229436 has been marked as a duplicate of this bug. ***
REOPEN: On my XP system: IE hands off to Windows Explorer. I'm not sure how this should work in Mozilla, but it should be reconsidered... From looking at this a lot more lately, I think the request is pretty reasonable, especially since we have an "up" link in URL's like this: file://///Home-users-comp/benc/ This also maybe fixable via bug 13607, because there seems to be a more general problem about Windows drives just not being displayed well.
*** Bug 73003 has been marked as a duplicate of this bug. ***
Changing OS to ALL. This also affects Linux as nautilus has network browsing. > Listing shares appears to be a small need that would require great effort to > implement. It's not clear why we need a web browser to list SMB shares. Agreed, and handled best by those writing the actual operating systems. We should hand off to Explorer on Windows and nautilus on Gnome, or otherwise whatever application has registered the smb:// protocol on Linux. Can the registered network browser (Explorer) be overridden on Windows? There should be no reason, for instance, people wouldn't be going to http://phynd.chewplastic.com/ on Linux. So the question is, what URIs should we accept... I have seen sites such as Phynd.net use URIs like: file:///\\netserv and file://\\netserv which both work in IE and Explorer and do the same thing as \\netserv nautilus handles smb:/// to simulate network neighborhood, and smb://netserv to be the same nas \\netserv is on Explorer IE and Explorer cannot handle smb:// nautilus cannot handle //netserv or file://///netserv and if you type // in bash, it will still accept it as the equivalent to / This is what I believe we should do: 1) We should handle smb:///, passing them off to Explorer as "Network Neighborhood" and nautilus as smb:/// 2) We should handle smb://someserver, passing them off to Explorer as \\someserver and nautilus as smb://someserver 3) We should convert the special cases file:///\\someserver, file:///\\someserver, and \\someserver to smb://someserver regardless of operating system. Handling //netserv could cause problems because currently, //usr does the same as /usr in Linux, and the slashes are backwards anyway from the way Windows does it. file://///usr also works in Linux, along with file://////////////////////////////////usr This bug is obviously one reason people would need to go back to using IE for some cases. Mozilla, without much work hand off to the registered handlers on the operating system.
*** Bug 236059 has been marked as a duplicate of this bug. ***
Btw, I think the summary is hard to understand and will likely not be found (as demonstrated by bug 236059. Should the summary be changed to "Handle URLs for samba shares (network neighborhood) and handoff to registered handler"? Bug 236059 mentioned that sometimes samba shares are linked to using file://sambaserver/ and that works in IE. Should we handle that, too? file://sambaserver/ would never be misidentified as a file, right? Would any of the schemes I mentioned interfere with nfs browsing (I've never tried NFS)? I just noticed that although \\netserv doesn't work on Firefox for Windows, \\netserv\shared works on Firefox for windows and shows the URL as file://///netserv/shared, which on Linux shows the directory /netserv/shared created via: netdragon1:(/)> mkdir netserv netdragon1:(/)> mkdir netserv/shared Typing \\netserv\shared on Linux brings you to http://www.independentcommerce.com/icDirectory/keyword.asp?keyword=netserv because of the automatic Google thing.. Not only does Mozilla not act consistently with IE's scheme, but it also isn't even consistent with itself. To summarize, the 5 schemes I mentioned are: 1) smb://netserv 2) smb:/// (equivalent to network neighborhood) 3) \\netserv and \\netserv\shared 4) file://\\netserv and file://\\netserv\shared 5) file://netserv 3,4, and 5 would redirect to 1. 1 would open Explorer or nautilus to the share, whereas 2 would open Explorer to "Network neighborhood" and nautilus to smb:///
Brian, please see my comments in your original bug, I think that this bug should be about shares at the file level, and we should open a new bug, or reopen your old bug, and make it be only about smb support. We can't do everything you want via one fix.
I'm hearing from a user who would very much like us to "Handle URLs for samba shares (network neighborhood) and handoff to registered handler." Pardon my ignorance and search failure, but if this bug is about something else, and bug 236059 is a dupe of this one, is there now another place to vote for that?
mass reassigning to nobody.
OK, here's a (hopefully) better bug description. On Microsoft systems, Firefox & family do not present file URLS in the same way as IE or Opera. In fact, firefox usually fails silently or without useful error messages. This is a major flaw for non-programmer users in a Microsoft or Microsoft-compatible (samba) environment. A Microsoft file share has a root, which functions like the root of a *nix filesystem or the MFD of a more highly evolved file system. The file reading and writing primitives of the Microsoft Windows family of operating systems can read all parts of a share that are accessible to users, including the root. File and directory protection mechanisms can be used to prevent or grant access, as you'd expect. So, as in the previously listed examples, a Microsoft Windows Server (or a linux/BSD/VMS server running samba) can publish a bunch of shares like so: //servername /share1 /share2 /folder2.1 /folder2.2 /share3 /folder3.1 /folder3.1.1 and so forth. This is commonplace in the windows world, and samba conforms to this scheme as well. An end-user running Microsoft Internet Explorer can click on URLs that are constructed in several different ways to get to the root share in the example shown above. Examining earlier posts in this bugzilla will demonstrate; most commonly, applications that use the technique will use URLs constructed with the prefix "file:" followed by five slashes and the servername. If one attempts this in firefox, literally nothing happens. No error, no diagnostic message, nothing. Completely windows-user hostile. If one attempts to click on a link to a specific share (usually constructed with a "file:" prefix, five slashes, a servername, a slash, and a share name) firefox will not present any message indicating that file URLs are a security hazard to the uninformed (they are) or that ff's treatment of file URLs is customizable by site and extremely wonderful (it is). Instead, they get nothing. Literally nothing happens. This makes firefox appear to be broken when compared to IE, and there are numerous commercial applications that appear to be unuseable with firefox for this reason. So, to sum up: #1 Firefox is incapable of visiting root shares and thus cannot be used in place of IE in many windows environments. #2 Firefox has better handling of file URL security hazards than any other browser, but because this is obscured from end-users, it is widely believed to be incapable of using local file links. #3 Firefox behaves entirely correctly when visiting non-root shares if the file URL is typed directly into the location bar. I believe this is because firefox does not pass UNCs to the MS-Windows operating system correctly, but I have not examined the code so this is little more than a guess.
(In reply to comment #33) I concur. When will this be addressed?