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: Sun, 18 Nov 2001 10:07:55 +0100
On Saturday, November 17, 2001, at 09:49 PM, Howard Oakley wrote:
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).
Yes, this seems to be an incremental improvement, which I just
implemented. However, it is not different in principle from the
<file>/rsrc approach: both rely on the fact that files don't have
'children' on other file systems. In the case of <file>/rsrc, trouble
might happen if <file> is a directory. In the case of
<file>/..namedfork/rsrc trouble could happen if <file> is a directory
with a subdirectory called '..namedfork', which is a perfectly legal
directory name, though I agree it is probably a rarer occurance.
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.
Agreed 100%.
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".
Exactly like hfstar.
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?
Well, Ondra is worried about the case where the user (a) unarchives into
an existing directory structure and (b) has plain files in the archive
that have the same names as directories on disk. What plain (gnu)tar
does, in this case, is not to not create that file (the directory being
in the way), and then continue unarchiving. That means that the <rsrc>
fork will then be added as plain file to the directory. With the
..namedfork/rsrc convention the same happens when (c) those directories
have subdirectories called '..namedfork'.
Since this addition makes problems even less likely, it seems like a
good idea to add, but just makes behavior slightly better in a situation
that is an error from the start.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.