GNOME Bugzilla – Bug 166577
g_filename_from_uri() doesn't handle UNC paths correctly
Last modified: 2011-02-18 16:14:20 UTC
Let's say your URI on a Win32 system is "file://server/foo/bar.png". g_filename_from_uri() returns "\foo\bar.png" and "server" as hostname. It should instead return "\\server\foo\bar.png" which is a perfectly valid UNC path on Win32 that can be opened as a local file. We workaround this problem in GIMP using file_utils_filename_from_uri() (see http://cvs.gnome.org/viewcvs/gimp/app/file/file-utils.c?view=markup). This workaround seems to work fine. It would however probably be better if this was fixed in GLib.
I think the correct form for a file: URI pointing to a file on a server share would be file:////server/share/foo.bar. Compare to URIs to files on a drive letter, their correct form is file:///x:/where/ever/etc. I think. Maybe. This is all very underspecified. (And throw in non-ASCII pathnames, it gets realy vague.) I really need to to some experimentation and check what contents Explorer puts in its Internet Shortcuts for files on servers. I don't know what file://server/foo/bar.png would mean. Is "\foo\bar.png" a valid pathname on the server machne? I.e. is it th same file as file:///foo/bar would refer to on the server machine itself? Or is foo an exported share (which need not correspond to a folder called "foo" (on some drive letter) at all? (Are file: URIs with non-empty hostname parts even specified on Unix?)
I will resolve this as NOTABUG. The URI file://server/foo/bar.png can't be interpreted locally. It isn't the URI representation of the UNC path \\server\foo\bar.png. The URI file:////server/foo/bar.png is turned into \\server\foo\bar.png by g_filename_from_uri(), as it should be.
Just FYI, per RFC, file:-URIs with nonempty hostname parts _are_ specifiedf to be servers on that hostname, using an unspecified access method. As such, making them equivalent to unc-paths is correct, as is not supporting them at all.