You're just complaining about one particular storage format for a file with
meta-data. You get the same unhappy result if you try to play with a JPEG
image file that's wrapped in tar(1) (gee, UNIX meta-data in front of the file.
Sound familiar?). Usually, things are only packed this way for transit, and
you're just missing the unpacking tool.

See the AppleDouble standard. That is essentially what is used by NetATalk
for storage of resource forks in UNIX filesystems for the AFP server: the
resource fork goes in a separate file so that a normal, boring UNIX program
can manipulate the data fork as a normal file with no special changes.

But this is about extensible meta-data for UNIX, for things like AFS and HSM,
not about Macintosh HFS.

If you wanna integrate extensible meta-data into UNIX properly, it needs
separate system calls, just like symbolic links, so that non-aware programs
work as always, and aware programs use the additional calls. This is not much
different than having open(2), close(2), read(2), and write(2) for playing
with the data, and chown(2), chmod(2), stat(2), utimes(2) for playing with
the meta-data. Do it really right, and chmod(2) becomes chmod(3), a library
interface to a more generalized file meta-data interface.

Given something like this, you can add ACLs easily, and other things.

	Erik E. Fair    fair@clock.org