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

[Lennart Borgman <lennart.borgman@gmail.com>]

On Thu, Sep 22, 2011 at 02:32, Juanma Barranquero <lekktu@gmail.com> wrote:
> 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".

Yes, but please remember if you make that interpretation (which I hope
is the correct one) then "c:/some/file.txt" is an absolute local file
name in URL file name syntax.

So if we hold on to that interpretation then maybe we should say (and
document ;-) that url-filename returns such a file name and that it
needs to be translated to the actually used systems file syntax to be
used there.

This would be an incompatible change from the current (faulty)
behaviour, but I think it would be the best.

> 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.

Ah, yes. I think we are saying the same thing about the problem here.

> 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".

That is a good example.