What is `our mechanism' ?
In order to make the discussion a bit more clear, it is probably necessary
to make this basic assumption more explicit. let's extend/change libc with the
notion of forks:
- some directories would be recognized by libc as "documents". Recognition
of those special dirs is based on a `typing' information (see below).
- new functions are provided to open a "document" (either a normal file
or a special directory), open forks in a document (files inside the
special dir), create a document, add forks, ...
- each file/dir has a `type'. The way this type is stored is unspecified.
it could be encoded in the name (and `extension' that automatically get
stripped in directory listings, for instance, or some other trick (magic
cookies for normal files, `readlink("<doc>/..type")' for dirs, ...)).
There are a few problems with this purely user-level implementation:
- playing with forks if you only have the openfile descriptor of some
part of a document is rather tricky. You'd need to keep the path around
or the containing (special) directory.
- hard links don't work between directories.
Those problems might or not be serious, I don't know.
Let's move on:
> * App developers WILL NOT agree to treat documents as files.
> * (if they do: all app developers suffer extra work & bloat)
I don't understand what you mean here.
> * Users will get very confused by directories that are documents.
Nope. The library clearly marks those as documents and not as directories.
The typing info makes it clear what is a directory and what is a document.
>> Are MacOS resource forks recursive? No.
> not very useful, and perhaps undesirable
> (normal users never look at the content structure directly)
Maybe not useful, but maybe useful, we n't know. In any case the suggested
scheme allows recursive forks seamlessly.
>> Can MacOS resource fork attributes have different permissions as the
>> base file? No.
> good - this is CRITICAL
> (user to tech support: "my word processor crashed...")
Nope. It is not critical at all. The word processor should simply complain
that something screwed up the access rights. It's the same kind of checking as
the checking already necessary (check that the fork is indeed there since
it might have been removed by a malicious user, a stupid transfer program,
...). Nothing new here.
Furthermore, you do sometimes want to have different access rights:
the main file might be executable (and maybe unreadable) while the forks
should not. Some of the forks might need to be writable (scores for games,
for instance), ...
>> Can MacOS attributes be symbolic linked across files to
>> save space and be more generic? No.
> good - this is CRITICAL
> (same sort of crash as above: broken links lose data)
Forks can disappear for all kinds of reasons. A broken symlink is no
different. It might be very useful to be able to put symlinks. It
might not be useful indeed, but then it's very easy to have the library
functions ignore symlinks if necessary. In any case symlinks are made
possible seamlessly if it turns out to be useful.
>> Directories are all 'Yes' to those questions, and they are
>> extremely fast with 2.2. Whats your problem with directories?
> Oh, no problem at all. They serve a different purpose though.
But the question is: should the kernel provide a notion of forks.
Since directories can provide this notion as well, the only reasons
why you'd want it in the kernel are things like efficiency (disk usage,
performance, ...) or consistency guarantees (atomicity, ...).
I agree with Hans Reiser that the standard file system should better support
this kind of use of directories, but I don't think that `forks' should be
added. Instead, it should be possible to have very efficient directories
(little disk use, fast, ...) which might require things like `dir-data in
inode' (XFS has that) and attribute inheritance. Also some kind
of support for typing info would be useful since `file(1)' is rather
clunky.
I for one disagree that forks should be supported by the kernel for a
very specific reason: they generally solve the wrong problem.
We do need a standard way to bundle things together, but "a file plus forks" is
not flexible enough. I want for instance to bundle together `ssh' and `scp'
so that I know they are always mutually-consistent. forks don't provide such a
functionality.
Forks are basically a very specialized kind of directories. Why not simply
use directories and get all those extra goodies ?
Stefan
-
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/