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

[Juanma Barranquero <lekktu@gmail.com>]

On Sun, Sep 25, 2011 at 01:42, Andreas Schwab <schwab@linux-m68k.org> wrote:

> If you interpret the local part as an absolute
> file name you have to prepend a slash after decomposing.  If not, then
> file:///etc/hosts wouldn't work as probably intended.

Of course. But that's not the point. The point is that how do you
interpret the local part is only important *after* decomposing the
URI. It's not url-generic-parse-url's task to do any interpretation.
Its docstring says just this:

  Return an url-struct of the parts of url.
  The CL-style struct contains the following fields:
  TYPE USER PASSWORD HOST PORTSPEC FILENAME TARGET ATTRIBUTES FULLNESS.

It says nothing of interpreting any of it, and specifically FILENAME,
POSIX-style. And if it does interpret it POSIX-style it is wreaking
havoc with Windows file: URIs (that's the whole point of this bug
report).

So, of course I agree with you when you say "If you interpret the
local part as an absolute file name you have to prepend a slash after
decomposing.", or more precisely, with what Lennart said previously:

> This is not about absolute path in the platform syntax. It is an
> absolute path as understood as part of an URL. That has to be
> translated to a platform path.

But this discussion is not about how to use the decomposed URI, is
about whether the decomposition is correct, or buggy (and so should be
fixed). I think the RFCs (the one I quoted and the ones you quoted)
show clearly that the current decomposition is erroneous, though
convenient for POSIX systems.

At this point, I can see only two options:

- Fix the bug, and fix also the places where the return value of
url-generic-parse-url / url-filename is assumed to be a POSIX absolute
path.
- Leave it as is, and implement some ad hoc hack to make it work with
Windows file: URIs.

    Juanma