On Mon, Aug 14, 2000 at 05:30:59PM -0000, Christer Weinigel wrote:
> vonbrand@inf.utfsm.cl wrote:
> > I read it as "If it can be supported in a sane way, we should do it". This
> > is insane, as are all the other schemes I've seen discussed here. And
> > "supported somehow" leaves a lot of non-kernel options open: Special tools,
> > a compatibility library, ...
>
> The "files as directories" way is a big deviation from how things work
> today, suddenly one can do opendir/readdir on a file which will
> confuse the hell out of some tools and tar won't be able to make a
> full backup anymore or be exported by NFS (i.e. wont fulfill no 1).
> It will fulfill no 3 and probably no 2 (at least work with those tools
> that aren't too smart look at each part of the path to check that
> those really are directories).
The "files as directories" and/or ".LinuxDouble" style solutions don't
really work cleanly as a VFS solution to support $(x)FS's NS/EA
functionality, but the reverse, a $(x)FS solution to support VFS's
NS/EA functionality, does work, or at least works better.
Once a VFS API can be hammered out that supports streams, it would
be trivial to implement a FS layer that does exactly what you're
describing. This is kinda how MacOS handles non-HFS media: by
creating a directory to store all the extra resource fork information.
This directory is used by some part of the OS and is not directly exposed
to the applications or the user, but rather is translated into the
resources that belong to the files. A stream-hack layer would similarly
create a directory or use extra flags or a dot-file or whatnot to make
it appear that there are streams on the filesystem despite the FS's
lack of support for such things, while at the same time playing by
the rules of the underlying FS.
Of course, if you mount it without the layer in-between, then you
can see whatever magic it implements, and potentially mess it up,
but nothing stop root from running rm -f /lib/libc.* either.
jf
-- John Franklin Interlan Communications franklin@interlan.net ICBM: 35°45'17"N 78°44'11"W- 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:34 EST