RE: [RFC] Pathname Semantics with //

["David Dabbs" <david@dabbs.net>]

> Christian Mayrhuber
> 
> What about using // as some URI entry point?
> An URI looks like:
> PROTOCOL://PROTOCOL_SPECIFIC_NAMESPACE_IMPLEMENTATION
> 
I considered that in that //: is implicitly file://, but didn't make it
explicit in the proposal. Perhaps //: could be a legal alias for //file://.


> ...
>
> If someone wants to expose filesystem metadata
> something like //metas:// instead of //: could do it.
> 
>       //metas://a-directory/SomeName      regular dir entry
>       //metas://a-directory//SomeName     named stream
>       //metas://a-directory///SomeName    == //metas://a-
> directory/SomeName
> 

But this means that metas:// becomes an alias for file:// depending upon
what you want to access. If we want to explicitly require a URI for files,
which may be the way to go, then there should be one protocol for file
access, file://. The semantics for that would be such that // on the end of
a file or directory means "access the named stream if the a) VFS supports
this and b) the device where the named object resides supports named
streams."  Programs that want to access named streams would use 

  //file://a-directory//SomeName

to access the streams as well as normal objects. Apps that exclusively use
the URI-style path would need to be more precise that is required today.
Today it works to concatenate "/home/" and "/"myfile" and references the
correct file. Under URI semantics, this would fail or not behave as
expected. 

David