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

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Thu, 3 Jun 2010 02:40:02 UTC

Severity: normal

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Lennart Borgman <lennart.borgman <at> gmail.com>, 6339 <at> debbugs.gnu.org
Subject: bug#6339: url-filename => "/c:/some/file.txt"
Date: Wed, 9 May 2012 13:52:42 +0200
On Wed, May 9, 2012 at 11:04 AM, Chong Yidong <cyd <at> gnu.org> wrote:

> In particular, RFC 3986 explicitly states that
>
>  If a URI contains an authority component, then the path component must
>  either be empty or begin with a slash ("/") character.
>
> That is to say, the / is part of the path.

This means that it is part of the "path" component of the URI, used to
separate and disambiguate, but does not say anything about how that is
interpreted as a a filesystem path. In this case (with no authority):

  file:///C:/windows/path

"/C:/windows/path" is the "path", but it is obviously not a filesystem path.

> So I think we should just explicitly state that the
> FILENAME slot is really PATH and QUERY together, and wash our hands of
> the matter.
>
> This also means that it should be up to callers to convert the FILENAME
> slot (i.e. PATH and QUERY) into proper filenames.  The translation from
> URIs to filenames is scheme-independent anyway, so it shouldn't be
> handled at the level of url-generic-parse-url.

I don't mind which way we fix it, but I'd be glad if we can avoid
snarky and erroneous "Windows does this wrong" comments in the code
while doing it...

    Juanma




This bug report was last modified 13 years and 17 days ago.

Previous Next


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