If one attempts this in firefox, literally nothing happens. 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.
#Unc mac program timeline windows
This is commonplace in the windows world, and samba conforms to this scheme as well.Īn 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. 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:Īnd so forth. File and directory protection mechanisms can be used to prevent or grant access, as you'd expect. 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. This is a major flaw for non-programmer users in a Microsoft or Microsoft-compatible (samba) environment.Ī 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. In fact, firefox usually fails silently or without useful error messages.
On Microsoft systems, Firefox & family do not present file URLS in the same way as IE or Opera. OK, here's a (hopefully) better bug description. Whereas 2 would open Explorer to "Network neighborhood" and nautilus to smb:/// 1 would open Explorer or nautilus to the share, To summarize, the 5 schemes I mentioned are:Ģ) smb:/// (equivalent to network neighborhood)ģ,4, and 5 would redirect to 1. Not only does Mozilla not act consistently with IE's scheme, but it also isn't Would any of the schemes I mentioned interfere with nfs browsing (I've neverĮtserv doesn't work on Firefox for Windows,Įtserv\shared works on Firefox for windows and shows the URL asįile://///netserv/shared, which on Linux shows the directory /netserv/shared Should we handle that, too?įile://sambaserver/ would never be misidentified as a file, right? Samba shares (network neighborhood) and handoff to registered handler"?īug 236059 mentioned that sometimes samba shares are linked to usingįile://sambaserver/ and that works in IE. Should the summary be changed to "Handle URLs for
Mozilla, without much work hand off to the registered handlers onītw, I think the summary is hard to understand and will likely not be found (asĭemonstrated by bug 236059. This bug is obviously one reason people would need to go back to using IE for Handling //netserv could cause problems because currently, //usr does the sameĪs /usr in Linux, and the slashes are backwards anyway from the way Windows does \\someserver and nautilus as smb://someserverģ) We should convert the special cases file:///\\someserver,įile:///\\someserver, and \\someserver to smb://someserver regardless of Nautilus cannot handle //netserv or file://///netserv and if you type // inīash, it will still accept it as the equivalent to /ġ) We should handle smb:///, passing them off to Explorer as "NetworkĢ) We should handle smb://someserver, passing them off to Explorer as Nautilus handles smb:/// to simulate network neighborhood, and smb://netserv to I have seen sites such as use URIs like: file:///Įtserv which both work in IE and Explorer and do the same thing as So the question is, what URIs should we accept. There should be no reason, for instance, people wouldn't be going to Registered network browser (Explorer) be overridden on Windows?
Whatever application has registered the smb:// protocol on Linux. Should hand off to Explorer on Windows and nautilus on Gnome, or otherwise It's not clear why we need a web browser to list SMB shares.Īgreed, and handled best by those writing the actual operating systems. > Listing shares appears to be a small need that would require great effort to This also affects Linux as nautilus has network browsing.