Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Howard Oakley <email@hidden>
- Date: Sat, 17 Nov 2001 20:49:57 +0000
On 17/11/01 14:52, "Ondra Cada" <email@hidden> wrote:
>
>>>>>> Marcel Weiher (MW) wrote at Sat, 17 Nov 2001 12:12:44 +0100:
>
MW> This is essentially what the hfstar patch to gnutar does: for each
>
MW> <plain-file> archived, also archive '<plain-file>/rsrc'. Nothing
>
MW> special needs to be done when untarring, it just works.
I think the /..namedfork/rsrc method is to be preferred, as it is the
officially documented HFS route. It is also guaranteed not to work on other
file systems (see below).
>
I don't think so. As I have recommended ages ago, I think it would be much
>
better to move those resource forks into a separate tree, rooted (using some
>
*QUITE* distinctive name) in /tmp. When unarchiving to HFS, the "macgnutar"
>
would catch this special name and restore resource forks.
However, it would then require special behaviour when unarchiving to UFS,
for instance - which does not of course root resource forks in a different
folder. In fact, this suggestion is the worst of both worlds, as it would
leave messy trash around on alien systems, and would not reflect the true
structure of any file system on a Mac.
>
The reason is simple -- to make the archive easily and without confusion
>
useable worldwide. Should you try to unpack archive of your design on, say,
>
Linux, you'll get a pretty mess. OTOH, should you unpack there "mine", you'll
>
get only some trash in /tmp, where it does not matter, and the real files
>
will be unpacked without any nonsense around.
Well, I cannot speak for other utils, but when handling hfspax archives, pax
(which does not of course handle the resource fork and finder info as hfspax
does) handles this without causing any "pretty mess" or "nonsense". Each
/..namedfork/rsrc or /finf component it finds, it cannot write out the
fork/info, so its spits out a little error message and skips on to the next
component. That way all the data forks are written out OK, and you know what
wasn't written out (by way of resource forks and Finder info). There's no
trash to clean up, nor would you have to try to work out what of that trash
might have been important - stderr lets you check that simply. What more
could you want or expect?
Howard.
Dr Howard Oakley * M1BWR: QRV on 2, 4 & 6 m SSB
EHN & DIJ Oakley * Internet email@hidden
Brooklands Lodge * CompuServe 70734,120
Park View Close *
http://www.quercus.demon.co.uk
Wroxall, Ventnor * voice +44 1983 853605
Isle of Wight, PO38 3EQ, UK * fax +44 1983 853253