Re: [RFC] Pathname Semantics with //

2004-09-10 Thread Hans Reiser
David Dabbs wrote: Before we get too far into the merits of implementation-specific pathname resolution for paths starting with //, it seems wise to address the POSIX implications of any duality implied by this (or any other) semantic change. This is the first issue raised in my original post.

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Peter Foldiak
see e.g. http://www.cs.bell-labs.com/cm/cs/doc/85/1-05.ps.gz On Wed, 2004-09-08 at 17:13, Hans Reiser wrote: Use of : in addition to / is a bad idea, see The Hideous Name by Rob Pike for why. Hans

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Christian Mayrhuber
What about using // as some URI entry point? An URI looks like: PROTOCOL://PROTOCOL_SPECIFIC_NAMESPACE_IMPLEMENTATION As no one can guarantee unix semantics in an URI space only symbolic links are allowed to and from the URL namespace. The protocol names are issued by the kernel to prevent

RE: [RFC] Pathname Semantics with //

2004-09-09 Thread David Dabbs
Use of : in addition to / is a bad idea, see The Hideous Name by Rob Pike for why. Hans I've read The Hideous Name, and I think you're taking Pike out of context. He wrote that document when device files were still only a part of a research version of UNIX. His main point is that

RE: [RFC] Pathname Semantics with //

2004-09-09 Thread David Dabbs
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://.

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Andreas Dilger
Christian Mayrhuber wrote: What about using // as some URI entry point? One problem that using // may have (thought it is personally my favourite option right now) is that realpath(3) may cause the // to be eaten, and this is used by many programs to resolve pathnames to remvoe symlinks, bogus

RE: [RFC] Pathname Semantics with //

2004-09-09 Thread David Dabbs
Before we get too far into the merits of implementation-specific pathname resolution for paths starting with //, it seems wise to address the POSIX implications of any duality implied by this (or any other) semantic change. This is the first issue raised in my original post. Gunnar Ritter also

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Jamie Lokier
Christian Mayrhuber wrote: //http://somehost:port/foo/bla While we're here, I'll point out that http://somehost/foo/bla and http://somehost/foo/bla/ are valid, distinct URLs. If http://somehost/foo/bla/ exists, many HTTP servers will return it as the target of a redirect for

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Hans Reiser
David Dabbs wrote: Use of : in addition to / is a bad idea, see The Hideous Name by Rob Pike for why. Hans I've read The Hideous Name, and I think you're taking Pike out of context. He wrote that document when device files were still only a part of a research version of UNIX. His main

RE: [RFC] Pathname Semantics with //

2004-09-09 Thread David Dabbs
From: Jamie Lokier [mailto:[EMAIL PROTECTED] Christian Mayrhuber wrote: //http://somehost:port/foo/bla While we're here, I'll point out that http://somehost/foo/bla and http://somehost/foo/bla/ are valid, distinct URLs. ... snip Food for thought. -- Jamie While I think there

RE: [RFC] Pathname Semantics with //

2004-09-09 Thread David Dabbs
Hans Reiser wrote: David Dabbs wrote: Use of : in addition to / is a bad idea, see The Hideous Name by Rob Pike for why. Hans I've read The Hideous Name, and I think you're taking Pike out of context. He wrote that document when device files were still only a part of a

Re: [RFC] Pathname Semantics with //

2004-09-09 Thread Hans Reiser
David Dabbs wrote: Do you have a proposal to expose metadata on a directory such that it a) allows one to distinguish a directory entry from directory metadata, this should be only a style convention, not a deep semantic difference. Maybe Peter can comment on this. b) uses only