Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Standard OS X Compression format

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.

References: 
 >Re: Standard OS X Compression format (From: "Andrew J. Hobbs" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.