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 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.

References: 
 >Re: Standard OS X Compression format (From: Howard Oakley <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.