bug#6339: url-filename => "/c:/some/file.txt"

[Juanma Barranquero <lekktu@gmail.com>]

On Thu, Sep 22, 2011 at 01:46, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> But unfortunately that might not be the right answer... Take this URL file name:
>
>   file:///c:/some/file.txt
>
> On windows that would be "c:/some/file.txt". What would it mean on a
> unix system? I guess it would mean "/c:/some/file.txt", but I am not
> sure. Perhaps that is an invalid file name on unix?

Quite likely, but IMO you're missing the point.

file:///c:/some/file.txt is a URL, i.e., it's a pointer to some
specific file in some specific place (or files with identical path and
name in different hosts, because the URL is missing the HOST part,
defaulting then to localhost). In fact, it is the URL that points to a
file, in some filesystem, with absolute path "c:/some/file.txt".
Whether that file exists, and whether that path makes sense when you
apply it locally to a POSIX system, i.e., whether you can access a
file with that URL, is irrelevant to the fact that "c:/some/file.txt"
is the path of the URL. You're muddling the waters when you insist in
"context" and "local system" and the like, because that affects to the
*use* of the URL, not its syntax. Splitting a URL into pieces
according to the RFC does not depend on where you do it or how do you
intend to use it.

We wouldn't be having this discussion in an alternative world where
the POSIX path separator was still "/", but the good people who wrote
the URI/URL specs had chosen "#" as the field separator in URLs:
file:##HOST#PATH

  file:###c:/some/file.txt  vs.  file:###some/file.txt

No one would try to split that as "#some/file.txt".

    Juanma