lkml.org 
[lkml]   [1998]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.176 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site