Kai Henningsen wrote:
>
> mmckinlay@gnu.org (Mo McKinlay) wrote on 14.08.00 in <Pine.LNX.4.21.0008141412260.10306-100000@sphere.man.uk.ekto.org>:
>
> > # But its not a file either, so if you can opendir it why cant you make it
> > # your cwd.
> >
> > IIRC people said that you should specifically NOT be able to
> > opendir() it. Being able to opendir() something that isn't a directory is
> > just as weird as being able to chdir() to it.
>
> I'm rapidly coming to the conclusion that any solution which does *not*
> allow an opendir() on it is just terminally broken.
It seems to me that allowing an opendir() on it would break apps in a
more subtle way than if we were to extend the VFS API. Some apps may
actually depend on the fact that opendir() returns an error on plain
files. Additionally, most filesystems that support multiple streams also
allow directories to have multiple streams attached to them.
I don't think there is going to be any clean way to fit this concept
into the UNIX namespace, because UNIX was never designed with multiple
streams per file in mind. The only clean way to do it, IMHO, is to add
new parameters/flags to the existing API, add new namespace tokens, and
modify our file utilities to be compatible. If MS managed to do it with
NT, our far superior programmers should have no problem at all ;).
Also, in case anyone is interested, here is what I know about the
multiple streams capabilities in some of our filesystems:
HPFS: Supports extended attributes natively and can attach EAs to
directories. Total EAs are limited to 64K per file (I think this was
only an OS/2 API restriction), and small ones are stored directly in the
FNode for fast access. EA names begin with a period (probably not a
filesystem restriction either); i.e. ".TYPE" and ".LONGNAME".
Incidentally, the .LONGNAME EA is quite useful as it allows files to be
named anything you want (you can even put a '/', '\', or a <CR><LF> in
the name). The OS/2 GUI uses this EA for the filename, and the HPFS FSD
automatically substitutes legal characters in the real name so that the
command interpreter doesn't choke on them. EA's also have type metadata
on them (ASCIIZ, binary, icon, etc). A good overview is available at
http://www.seds.org/~spider/spider/os2/hpfs/ea.html
JFS: Same as HPFS, but EA sizes are unrestricted and EA access seems
slower.
-- Mark McClelland mmcclelland@delphi.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:36 EST