Re: File URIs, home and relative paths

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