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

Previous Next

Full log

Message #98 received at 6339 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 6339 <at> debbugs.gnu.org,
	Jason Rumney <jasonr <at> gnu.org>
Subject: Re: bug#6339: url-filename => "/c:/some/file.txt"
Date: Sun, 25 Sep 2011 02:02:03 +0200

On Sun, Sep 25, 2011 at 01:42, Andreas Schwab <schwab <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.