Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman,

[Albert D. Cahalan]

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.