[mpweiher]

>Applications — even basic filesystem tools — aren't aware of the additional content.

That's not actually true. Most if not all Unix utilities have been updated to deal with resource forks, and they have been integrated into the Unix directory hierarchy by treating the actual file as a single level directory.

The fact that the resource fork is invisible by default is the most reasonable way I can think of. Other options such as concatenating all the forks together or treating the file itself as a single level directory by default would actually break everything.

The solution that they found is to have this interpretation (the file is really a single-level directory) accessible, but make one fork (the data fork) the default "bag of bytes" for most of the Unix tools.

For example:

   file  /tmp/Euclid/..namedfork/rsrc
   /tmp/Euclid/..namedfork/rsrc: MS Windows icon resource

Well, wrong answer, but correct access to the file.

That was a copy of a resource-fork based font I created by typing:

    cp Euclid /tmp/

The `cp` command copied the resource fork just fine. tar was also updated to handle resource forks and other metadata. I know this because long ago I created `hfstar`[1] to do just that, because the tar that came with the OS hadn't been updated yet. Today, hfstar is no longer necessary.

[1] http://www.macupdate.com/app/mac/9405/hfstar