Re: UNC paths, glib, and the file chooser

[Tor Lillqvist <tml iki fi>]

James Henstridge <james jamesh id au> writes:
 > Internet Explorer canonicalises UNC paths to URIs as
 > file://hostname/share/path, while mozilla canonicalises to
 > file://///hostname/share/path.

Sven Neumann writes:
 > It's not only IE. GtkFileChooser on Win32 also seems to return
 > file://hostname/share/path URIs for files in UNC paths.

Maybe, but... that's not necessarily a deliberate design choice. It's
not like there would have been lots of people discussing the design
and implementation of gtkfilesystemwin32 before commotting to some
design choice. Actually, now that you bring it up, it seems
wrong. Isn't a file: URI where the host name isn't empty or
"localhost" meant to contain a path that's interpretable on the host
in question?

A path starting with a share name is not something the machine
providing the share in question would necessarily be able to
recognize. The local path corresponding to a share can be in a totally
random location on a random drive, and need not even have the share
name anywhere in the path. For instance, a machine "mybox" might have
a C:\foo\bar\zap folder, shared as "foo". What would
file://mybox/foo/file.txt refer to if interpreted on mybox (in a
process whose "current drive" is C:)? C:\foo\file.txt or
C:\foo\bar\zap\file.txt?

Hmm, or maybe it is unambiguous, after all. True absolute local
pathnames should start with a drive letter, right, so a local part
starting with /foo/ must mean whatever location in the local file
system is shared under the name "foo", yes?

Seen like that, if a process on mybox would like to produce an URI
that unambiguosly refers to a file on that machine (and that machine
only), it would use something like file://mybox/c|/foo/bar/goat.png,
right?

--tml