Linux-kernel mailing list archive 1999-25,: Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and

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

Nathan Hand (nathanh@chirp.com.au)
Thu, 24 Jun 1999 17:54:33 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: J.W. Hoogervorst: "RE: Massive e2fs corruption with 2.2.9/10? (memory problem)"
- Previous message: Alan Cox: "Re: RFC: BSD system call revoke?"
- In reply to: Bill Huey: "Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and"
- Next in thread: Albert D. Cahalan: "Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and"

On Tue, Jun 22, 1999 at 03:35:50PM -0700, Bill Huey wrote:
>
> > One of the reasons why the Apple resource-fork was a really sucky idea
> > in practice was that executables stored dialog boxes, buttons, text, all
> > in resources --- which would get lost if you tried to ftp the file
> > unless you binhexed or otherwise prepped the file for transfer first.
>
> Oh, you're brain-dead shut the hell up...
>
> Macintosh resource forks are somethat you you either "get" or don't "get".

You can "get" something without agreeing with it.

> Coming from a Macintosh background and working with Macintosh OS internals,
> I can't imagine that OSes live without and additional stream per file.

Not only are you offensive, but you're wrong.

In practise the difference to the user between systems with streamed files
and one like UNIX without streamed files is zero. The unstreamed system is
simply required to use a filename per fork, and operations that modify any
file must modify all forks appropriately.

This is harder if you're trying to preserve backwards compatiblity with an
army of programs which don't understand forks, but is trivial for a system
being designed from the "groundup" to be only accessed through a graphical
file manager. All GUI applications just need take care.

It doesn't even make the job any harder for the programmer. They just need
to use forked variants of common filesystem operations ie. frkopen().

Now you can argue that forked filesystems have other benefits (speed, code
size, simplicity) but the fundamental benefit is achievable on filesystems
without streamed files. Even things like locking and atomic operations are
not a hinderance with "faked" streamed files.

> The BeOS does some pretty outstanding stuff with file attributes and
> like. OpenStep hack this stuff in using directories, but it still was
> pretty effective since I was designed correctly.

It's not a hack. It's just putting the code in userspace, not the kernel.

> [horribly offensive content deleted]

Is this really necessary?

    --
    Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
    Phone: +61 2 6230 1871   Fax: +61 2 6230 4455   E-mail: nathanh@chirp.com.au

    -
    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/

- Next message: J.W. Hoogervorst: "RE: Massive e2fs corruption with 2.2.9/10? (memory problem)"
- Previous message: Alan Cox: "Re: RFC: BSD system call revoke?"
- In reply to: Bill Huey: "Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and"
- Next in thread: Albert D. Cahalan: "Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and"