Messages in this thread | | | Subject | Re: Implementing Meta File information in Linux | From | Benny Amorsen <> | Date | 02 Sep 1998 11:27:03 +0200 |
| |
I have a proposal which I think takes into consideration all the objections people have made so far.
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
| |