Re: named streams, extended attributes, and posix

On Thu, Jan 25, 2001 at 02:07:11PM -0700, Thunder from the hill wrote:
> Daniel Phillips wrote:
> > For some reason totally beyond my comprehension // inside a file name is
> > taken to be the same as /, but if it wasn't it could be the stream
> > separator.  *sigh*
> It seems that you mix up forward and backward slashes. a // means //,
> but a \\ means a single \. So if you want a double backslash, you have

No, he's referring to the fact that multiple path separators ("/") in a file 
specification are collapsed to be equivalent to one.  Thus "/some//file///path"
is equivalent to "/some/file/path" as far as the system is concerned.

This is actually a very handy thing, IMHO, and avoids tons of 
trailing-slash/leading-slash special-case logic in apps, not to mention subtle 
bugs resulting from lack of same as I have encountered way too many times on 
other platforms...

I agree however, that it would perhaps have been nice if POSIX hadn't been 
quite so gung-ho about any-character-under-the-sun-is-ok-in-filenames so we had a couple of reserved characters to play with down the line..

Here's an idea: streams/etc are reached by appending "/.../xxx" or some 
such to paths, thus:
  for streamname on /dir/file, we have "/dir/file/.../streamname" 
    -- a few more characters to type but no big deal really,
  for a directory /dir/dir, we get /dir/dir/.../streamname" 
    -- "..." is a special subdirectory of any directories which have 
    attached streams.  If the name of such a directory is chosen well 
    (personally, I think "..." is a good choice as it goes well with "." and 
    ".." as a filesystem-intrinsic name), this is much less likely to 
    conflict with normal filesystem namespaces.

This also has the advantage of being extendable (using strings other than 
"...") for other applications or future additions.

-alex