Messages in this thread | | | Date | Wed, 02 Sep 1998 03:04:45 -0700 | From | Hans Reiser <> | Subject | Re: Implementing Meta File information in Linux |
| |
We can even do it one better: if there is no default file in the directory, we return EISDIR when we read the directory.
Hans
Benny Amorsen wrote:
> 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
| |