🚀 go-pugleaf

David Findley wrote in comp.sys.powerpc about "Re: Macintosh Resource Forks
and the BeBox":

> The resource fork is just an ordered sequence of bytes, exactly like the
> data fork.  In a single fork file-system, the catalog entry of a file
> contains a pointer to the first block of the file (among other things),
> in the MacOS filesystem, there are two pointers instead of one (again,
> among other things).
>
> The difference is that there are routines in ROM for managing the
> resource fork as a kind of mini-database, and all applications
> (including the Finder) tend to make use of this.  Of course, you can
> access the resource fork directly byte-by-byte and use it as just
> another data fork if you want.  Since there is already a data fork
> provided for flat access, most (if not all) apps use the resouce fork in
> the way that it was intended; there is really no need to do otherwise.
>
> David Findley davidf@kepler.umsl.edu

(Sorry, this is getting a little off-topic for the BeBox, and definately
off-topic for the PPC chips...)

It seems to me like a resource fork is just a file with a very standardized
structure, like IFF.  Why can't the data fork be _included_ in this
structure?  If the file is a program, it could have an "executable" chunk.
(Or better yet, a 68k executable chunk, a PPC executable chunk, etc.)  If
the file is a word-processor document, it could have a text chunk.  And,
of course, unlimited combinations.

Why not?  By combining the forks, we could get back to a single-fork (i.e.
more "conventional" *shudder*) file system.  No?

   Yog-Sothoth Neblod Zin,
      Sloppy