Messages in this thread | | | Date | Wed, 23 Jun 1999 21:37:57 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, |
| |
Ingo Molnar writes: > On Tue, 22 Jun 1999, Bill Huey wrote:
>> You can just search the data fork for content. > > why should we add such a restrictive construct to the kerenel, if we > already have a mechanism that does this and more.
Our mechanism also does less. It can not hide the distinction between a blob of binary data and a structured document. This distinction is necessary for good compound document behavior.
Dumb file problems:
* App developers need to create an internal namespace. * Components that grow must suffer reallocation. * The big bloated files this causes will need garbage collection.
Dumb directory problems:
* App developers WILL NOT agree to treat documents as files. * (if they do: all app developers suffer extra work & bloat) * Users will get very confused by directories that are documents. * Tech support will want your head on a stake. (broken documents)
> Are MacOS resource forks recursive? No.
not very useful, and perhaps undesirable (normal users never look at the content structure directly)
> Can MacOS resource forks be files? No.
good - you are confused
> 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...")
> 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)
> Can MacOS resource fork attributes be > different things to different users in a multiuser environment? No.
not important, and perhaps undesireable (this is silly: can /bin/bash be different...)
> 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.
- 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/
| |