Enhancement: Cannot expand more than one contained archive in sucession

[cjt5132]

Enhancement: Cannot expand more than one contained archive in sucession

[GoogleCodeExporter]

I believe the Unarchiver already does 'continue to expand' archives like 
Expander
does, with the exception of mounting disk images.
On a related note though, Expander's 'continue to expand' feature will 
additionally
decode any .hqx or .bin encoded files that it finds [i]anywhere[/i] within the
archive. This is an extremely useful feature for me and I would be very 
grateful if
The Unarchiver could do this too.

Original comment by [email protected] on 4 Jan 2007 at 9:07

[GoogleCodeExporter]

Well, first, .dmg is not an archive. A disk image is not something The 
Unarchiver
can't easily handle on its own (although libxad does have support for disk 
images, it
doesn't have the HFS+ implementation which would be needed to read it). So it 
would
have to pass off the file to the rest of the system, and this is tricky for 
security
reasons. Just having The Unarchiver open folders it extracts is dangerous, and 
I am
not sure I want to add any further possibilities for vulnerabilities. Also, dmgs
shouldn't be distributed inside archives in the first place, as they can have 
their
own compression. This seems an unlikely enough case that it doesn't really 
warrant
the extra code to handle it.

If there was a way to mount the file directly from the program instead of 
passing it
to the OS to do, I might consider it. I haven't checked.

As for actually opening archives inside other archives, currently The Unarchiver
handles the common cases like tar.gz and sit inside hqx by directly unpacking 
the
inner archive without an intermediate step. Other cases of archives within 
archives
seems to also be rare enough that I am not sure if it is worth the bloat to add
support for that, especially when this isn't desired behaviour in all cases 
anyway.

Original comment by [email protected] on 5 Jan 2007 at 1:44

[GoogleCodeExporter]

So for the archives insides archives, does it just do some specific cases you've
defined or any case where the archive contains a single file which is also an 
archive?

For files elsewhere in the archive, Expander just does encoded files and not 
other
archive or compression types. I'm going to beg for The Unarchiver to do the 
same. You
could have the checkbox in the preferences and have it work just like Expander.
Pleeease :)

Original comment by [email protected] on 7 Jan 2007 at 11:42

[GoogleCodeExporter]

(As an example of why I was talking of security issues, see
http://projects.info-pull.com/moab/MOAB-09-01-2007.html)

Original comment by [email protected] on 10 Jan 2007 at 1:35

[GoogleCodeExporter]

So that's for disk images, what about encoded files? :)

Original comment by [email protected] on 27 Jan 2007 at 10:23

[GoogleCodeExporter]

I'm not convinced this is a common enough occurance that it is worth it. Nobody 
has
used hqx or bin in years, so this seems to be strictly for legacy use, and even 
so,
sit-in-hqx is by far more common than hqx-in-sit, which I have personally never
encountered.

Original comment by [email protected] on 28 Jan 2007 at 11:06

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Well okay then, I understand. I guess it is only one specific purpose it would 
serve.

Original comment by [email protected] on 29 Jan 2007 at 12:30

[GoogleCodeExporter]

Actually, just a bit more info on Macbinary inside archives, prior to the 
invention of apple double and OS X 
supporting macintosh data in zip and tar archives, Macbinary was a common 
method of preserving the 
macintosh data so the files could be safely stored in such archives. DropZip 
used to allow 'smart' Macbinary 
encoding which would do this for you and thus Expander was made capable of 
extracting such an archive all in 
one go without anyone ever having to see the macbinary files. Other programs 
like TarPit (http://
macupdate.com/info.php/id/14443) also do Macbinary encoding. So while it isn't 
really used any more, old 
archives like this are still around.

Original comment by [email protected] on 23 Feb 2007 at 8:28

[GoogleCodeExporter]

In that case, it would make more sense to add some code to handle this 
transparently,
like how AppleDouble files are currently handled. I don't have any example 
files to
work with, though, and I am not sure if the files can be reliably detected, as 
".bin"
is a common enough file extension for all kinds of different files. If the 
actual
archives that use it use some special trick to mark the files, it would make 
things
simpler.

For now, if anybody could submit some test cases, that would help.

Original comment by [email protected] on 23 Feb 2007 at 4:25

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Well here's some code for encoding and decoding macbinary. I'm not sure how 
much it's been modified from the 
original but the part you're interested in is just the headerismacbinary bit. 
As for a test case, all you need to do is 
encode some files and them zip them together ;-)

Thanks for doing this though, much appreciated.

Original comment by [email protected] on 24 Feb 2007 at 1:24

Attachments:

• macbinaryIII.zip

[GoogleCodeExporter]

No, what I want to do is detect the format without looking at the contents, as 
doing
that is expensive. And I'd really want a file created with the apps that 
actually do
this, to see if they do it in any special way, such as naming the files in some
particular way.

Original comment by [email protected] on 24 Feb 2007 at 1:59

[GoogleCodeExporter]

Ah, I see. Well no, they don't do anything special - they just encode the files 
and then archive. On expansion, 
StuffIt Expander will try to expand any file with a .bin extension and if it 
finds it can't it'll pop up a message 
saying something like "File x does not appear to be compressed or encoded".

Original comment by [email protected] on 24 Feb 2007 at 8:17

[GoogleCodeExporter]

That's not exactly elegant... sigh. I'll see what I can think up.

Original comment by [email protected] on 24 Feb 2007 at 8:36

[GoogleCodeExporter]

Actually, bug 56 turned out to be about a zip file containing a MacBinary file 
that
is *not* named .bin, yet StuffIt still recognizes it. It seems that it does not 
rely
on the name.

I really need some further test cases for this, encoded with a version of 
StuffIt
that does this kind of thing automatically!

Original comment by [email protected] on 4 Mar 2007 at 3:08

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

That's interesting. I'll get some test cases to you sometime this weekend.

Original comment by [email protected] on 5 Mar 2007 at 9:56

[GoogleCodeExporter]

I found the mechanism used, and it's actually briefly documented in the zip 
specs.
Seems the (probably old) Mac app "ZipIt" defined some Zip extensions for storing
creator/file types, and for marking a file as being MacBinary encoded. Working 
on
implementing those right now. Some test cases would indeed be helpful to see if 
it
works on anything but the mysterious Gothic.zip file.

Original comment by [email protected] on 5 Mar 2007 at 10:00

[GoogleCodeExporter]

Ahhh, even more interesting. Can you point me to somewhere I can find out more 
about
that? We'll have to see if DropZip does it the same way or not.

Original comment by [email protected] on 8 Mar 2007 at 2:09

[GoogleCodeExporter]

Search for "ZipIt" in http://www.pkware.com/documents/casestudies/APPNOTE.TXT.

Original comment by [email protected] on 8 Mar 2007 at 2:13

[GoogleCodeExporter]

Thanks. I just found some other info somewhere which said DropZip does indeed 
use the
same method.

Original comment by [email protected] on 8 Mar 2007 at 2:19

[GoogleCodeExporter]

Okay, here are a bunch of test cases. BAH contains the original test folder 
completely intact, I've also compressed 
it with ZipIt, DropZip and MacZip, all on OS 9 (MacZip uses some other weird 
method, probably shouldn't worry 
about that one). And finally the Manual archive is one where I did the 
necessary encoding myself before zipping 
from the command line.

Original comment by [email protected] on 10 Mar 2007 at 11:48

Attachments:

• ZipIt.zip
• DropZip.zip
• MacZip.zip
• Manual.zip
• BAH.zip

[GoogleCodeExporter]

Wait, the DropZip smart encoding didn't work properly. I've just attached a new 
DropZip archive (using DropZip 8 
on OS X).
So the only important thing here is to recognise the macbinary files (in the 
ZipIt and DropZip archives, plus 
Manual if feasible) and decode them transparently. None of that other info 
stored in the zip file really matters. 
Although perhaps one smart thing to do would be to enable the folder icon flag 
if an encoded Icon file is found 
inside the folder - it's strange how DropZip preserves the Icon file by 
encoding it but Expander can't restore the 
folder flag on extraction.

Original comment by [email protected] on 11 Mar 2007 at 2:12

Attachments:

• DropZip.zip

[GoogleCodeExporter]

I finally got around to finishing the required internal changes for this.

Current status: ZipIt files work, except that the ZipIt.zip file up there 
apparently
does not include the Icon^M file for the folder, and thus it does not get an 
icon.
DropZip and MacZip files do not work. DropZip does not use the ZipIt extension 
to
mark its MacBinary files, and I can't really do anything to fix this. MacZip 
uses its
own file format and directory structure, apparently, and I don't really feel 
like
putting in the effort to support that.

I think I'll close this bug for now, as this is as close as I'll get it right 
now,
but feel free to post more information if you find it.

Original comment by [email protected] on 19 Mar 2007 at 3:34

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for your work :). Strange that DropZip doesn't use the same extesions 
ZipIt
does - the article I read implied that it did. While I couldn't care less about
MacZip (I only discovered it existed while checking out all this zip stuff and I
hardly think it was used much seeing as no other program can properly extract 
the
files it creates) I think DropZip was used far more commonly than ZipIt was so 
even
if it requires 'ugly' methods like attempting to decode any .bin files and 
ignoring
it if it fails then I would be very happy with that.

Original comment by [email protected] on 21 Mar 2007 at 12:01

[GoogleCodeExporter]

Since I've been rewriting a lot of the core of XADMaster, it's now a lot easier 
to
support the MacBinary forks in formats that don't mark them explicitly, so I 
added
support for those. Manual.zip and DropZip.zip seem to work fine now. Needs more
testing later, perhaps.

Original comment by [email protected] on 13 Feb 2009 at 2:38

[GoogleCodeExporter]

Hi paracelsus, thanks so much for your support!
It seems to work fine except that the decoded files always end up in the root 
of the 
extracted archive, rather than the original path of the encoded files. In the 
example 
archives above, the file "ResEdit" should be extracted to "Test/Folder with 
icon".

Also another small issue with MacBinary decoding: the hi and lo Finder flags 
are the 
wrong way around 
(http://code.google.com/p/theunarchiver/source/browse/trunk/XADMaster/XADMac
ArchiveParser.m#276)

Original comment by [email protected] on 25 Oct 2009 at 4:16

[GoogleCodeExporter]

Oh, I knew about that bug but I forgot to fix it. Gonna try to get around to 
doing that 
soon.

Original comment by [email protected] on 25 Oct 2009 at 12:37

• Changed state: Accepted
• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

There, fixed again.

Original comment by [email protected] on 15 Nov 2009 at 7:30

• Changed state: Fixed