Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Marcel Weiher <email@hidden>
- Date: Sat, 17 Nov 2001 12:12:44 +0100
On Friday, November 16, 2001, at 06:05 PM, Andrew J. Hobbs wrote:
<asbestos_underwear>
Rather than a new "standard", going with something like tar.gz would be
much preferable. True, it doesn't understand resource forks, but
preferred mode for OS X is resource in data fork of a seperate file.
Perhaps modifying (and providing patches back) to the existing
utilities to gracefully handle forks.
Gosh, that sounds like a good idea.. :-)
Actually, the tar format is quite capable of storing resource forks, tar
just doesn't know how to look for them. If you tell it that the
resource forks are there, it will happily archive them. Here's how:
- get a directory listing
- duplicate it and append '/rsrc' to each entry
- now tell gnutar to archive the files from these two listings
Voila, resource forks in tar, nothing special needed.
This is essentially what the hfstar patch to gnutar does: for each
<plain-file> archived, also archive '<plain-file>/rsrc'. Nothing
special needs to be done when untarring, it just works.
That leaves the finder info, which hfstar puts into special blocks like
the ones gnutar uses for long filenames.
Something like this:
Bundle files into the tar the same as if OS X was sticking files onto a
UFS or foreign NFS drive, by putting resources in an external file.
When decoding, automatically reassemble if the filesystem supports
forks, or leave in the accepted format on others.
This is another possible way of handling it, but it has a drawback that
I consider quite serious, at least in a backup/archival tool: as far as
I can tell, it will sometimes destroy perfectly valid files because of
filename collisions. All you need is a plain file (on HFS) that has
exactly the name as a mapped resource fork. On unpacking, this will
destroy either the resource fork of the one file or the data fork of the
other.
While such occurances will probably be rare due to the filename
conventions, Murphy says that they will happen just when you can least
afford to have it. And in fact, what if you have files that need to be
in Apple Double (or comparable), for example for serving over a
non-fork-aware file-sharing protocol, but stored on an HFS+ volume?
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.