Currently it is not allowed to read() a directory in linux. Instead,
make read() on a directory actually read the file directory/default.
Now, most programs never check whether the read() is possible, they
just fail with EISDIR. In this scheme they would work perfectly.
Archival programs on the other hand usually explicitly check whether a
file is a directory. They would not attempt the read() and therefore
they would just archive the directory and the files it contains. They
too would work perfectly.
A few applications would get smart and retrieve the files contained in
the directory, for instance icon data.
>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
ESR> 1. If you get the design of something wrong, it's a lot easier to
ESR> change or unwire it if it lives in an API library than if it
ESR> lives in the kernel. We *will* get the metadata design wrong the
ESR> first time. Let's do our prototyping in user space, guys, to hold
ESR> down the number of potentially destructive interactions.
If this thing fails we can just go back to returning EISDIR for files.
The applications that took advantage of this scheme would break, but
in the beginning that wouldn't be very many applications. Also, those
applications would probably contain backup methods for use on systems
that do not support forks.
ESR> 2. The right way to think about the Unix file system as it is is
ESR> that it's just a namespace manager -- a mechanism that takes
ESR> pathnames and gives back byte streams. Resource forks at fs level
ESR> would be bad design because they would complicate that
ESR> abstraction. This is a good reason to avoid doing them unless
ESR> there's some overwhelming and obvious gain to be had for the
ESR> complexity added -- and I don't see one.
This way the file system would still be taking pathnames and giving
byte streams.
ESR> 3. This kind of level-mixing mistake has already been made once.
ESR> System- V-style file locks should never have been implemented in
ESR> the kernel; it would have sufficed to implement them via a shared
ESR> library with a few tricks. Instead we got kernel bloat. Let's not
ESR> make this error again.
The kernel bloat in this case is very very minimal. No added system
calls -- just one error condition instead turned into doing something
useful.
Benny
-
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