While we wait for the clean solution, can we adopt a convention of naming
the directory filename.forks, and putting all the subforks in filename.forks?
I do not think that subforks should be hidden in dot files: that will mean that users
will leave things behind when they do moves, and then not know why things
don't work.
Can we tell the NFS standards body that in two years we want to support files that
are also directories, and ask them to join us in support for it in two years?
Whatever we do, let us agree that the MS structured storage approach is the wrong
answer. Use of directories is much cleaner semantically. ReiserFS directories are
more space efficient for small subforks than MS structured storage, as well as being
higher performance. Structured storage allocates in 512 byte units.....
Hans
Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, 31 Aug 1998 15:08:34 -0700, Hans Reiser <reiser@idiom.com> said:
>
> > With regards to namei() in general:
>
> > I think that what you are failing to realize is that it is possible to
> > change namei() while retaining upward compatibility.
>
> > I have a complete set of semantics designed for namei() which are
> > based on what russians would call set-theoretic database theory.
> > These semantics give you everything that a keyword system or a
> > database can give you but with greater generality and abstraction.
>
> That's fine. I have no objection to that, but that's not really what
> the discussion about forks started off as.
>
> The issue was about adding extra streams to a file in a way which does
> not change the visible contents of the file as seen by a normal open().
> It's not an issue of keeping the "main" contents of the file in a
> subfork; it's a question of adding subforks _without_ disturbing the
> main contents. That, by definition, changes the semantics of namei():
> you no longer get the whole contents of the file back when you do an
> open() and read().
>
> That is the crux of my objections. If we add such hidden information,
> then all our current tools (NFS, tar, cp, mv etc) fail. NFS in
> particular is a killer: by adding functionality to the fs which cannot
> be encoded in the standard NFS protocol, we lose the ability to share
> these files.
>
> If we want to add tagged information to a file, far better to do it via
> a dot directory. Keep the problem in user space where it belongs. Any
> extra efficiency that the fs has to offer will still be realised by such
> a mechanism.
>
> Only where the kernel *has* to be involved (such as for security issues)
> can we justify adding the fork in the kernel. That alone justifies
> having fork capability in the kernel. It does not justify adding a
> generic fork API to the kernel; far better to have a separate ACL API
> and let each filesystem deal with it in the most appropriate manner.
>
> Cheers,
> Stephen
-
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.altern.org/andrebalsa/doc/lkml-faq.html