W3C home > Mailing lists > Public > uri@w3.org > June 2016

Re: File URIs, home and relative paths

From: Jason Dusek <jason.dusek@gmail.com>
Date: Sat, 11 Jun 2016 19:56:10 +0000
Message-ID: <CAO3NbwNaNpahYWy6evy3R=1htBBueEuKQA__+Mz=mzJqK4-m7A@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: uri@w3.org
On Fri, 10 Jun 2016 at 18:08 Matthew Kerwin <matthew@kerwin.net.au> wrote:

> Hi,
> I'll reply to the part I can talk to.
> On 10/06/2016 2:38 PM, "Jason Dusek" <jason.dusek@gmail.com> wrote:
> >
> > In the draft RFC, some allowance is made for UNC paths, which result in
> runs of slashes like this file://///... UNC provides a notion of a share
> and perhaps we could treat home, dot and dot dot as shares?
> Using file://..././/.., file://.../~//..., &c.
> >
> I don't see how to make this work. The concept of a 'share' is unique to
> MS-DTYP. All we have in a file URI is a path.
> And, again, one has to take care with names like '.' and '..' since those
> are destroyed by any RFC 3986-compliant general purpose URL library.
> > Another possibility is to make use of a reserved character, the @, as a
> mysterium bonum. We imagine a virtual directory at file:///@ wherein:
> >
> > file:///@/. is a link to the present directory as defined by the end
> user’s context,
> > file:///@/.. is the directory above this directory,
> > file:///@/~ is the end user’s home directory.
> >
> > To access a file or directory @ at the system root, one can
> use file:///%40. Is this something that a conforming implementation could
> provide under the present draft?
> >
> That's syntactically legal. I also think there's nothing in the current
> draft that forbids it, because I realise on a fresh reading that the part
> of the draft that used to explain how the 'path' of a URI relates to the
> local file system has vanished. I'm going to have to re-add it. It will
> describe what everyone currently does and expects: the URI path represents
> an absolute file path.
> Since '@' is explicitly allowed in the `pchar` rule used in path segments,
> I think "/@/..." would not be special-handled by most implementations; so
> you're going to have interoperability issues trying to do this.
Well, this clarifies some things. Magic mounts are, I think, within an
implementer's rights; and here, percent encoding does provide a way to
escape the special interpretation.

It is strange to me that the draft neither provides for home and the
present directory semantics, nor clearly speaks to the issue (in a section
titled "Special Paths in UNIX and File URLs" or something similar). Perhaps
it would inspire future work in this area.

> > Kind Regards,
> >   Jason Dusek
> >
> Cheers,
> Matty
Kind Regards,
  Jason Dusek
Received on Saturday, 11 June 2016 19:56:49 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 11 June 2016 19:56:50 UTC