Well, after a far too long development cycle, The Unarchiver 2.0 is starting to come together. The reason for the massive delay is that huge parts of the internals have been rewritten to make it easier to program and extend. The old libxad is mostly gone except for old formats, and new Objective-C based code handles most normal formats.

Of course, that kind of huge rewrite will have introduced a lot of new bugs, and I really need some help testing it to shake those bugs out. So if you want to help out, you should grab it and try to use it on any files you can find, and report to me if it doesn't work as expected, preferably with the files that cause problems included.

The latest version can be found here:

http://code.google.com/p/theunarchiver/downloads/list

Obviously you should be aware that this may cause all kinds of problems, so be prepared to downgrade in that case.

Further information in later posts. Try to read the thread before reporting bugs!

The current version is 2.0, alpha 1: http://theunarchiver.googlecode.com/files/TheUnarchiver2.0alpha1.zip

This version contains only changes to the internal engine, and no changes at all to the interface! Old bugs on the bug tracker about the interface have not been fixed yet, so no need to re-report those. If something that USED to work doesn't work any more, though, I want to hear about it.

New things in 2.0 alpha 1:

• Partial SITX support. Most compression modes in SITX should work fine, except the JPEG compression mode which was just too huge to reverse engineer properly. If anybody wants to help out and get that working, I'd be incredible grateful.
• RAR encryption support. Should work, maybe. Test it out, and also test if any of the other RAR problems have been fixed by the rewrite!
• Support for WinZip-style AES encryption in Zip.
• Support for some more obscure Mac OS-specific Zip extensions.
• Support for some more old Mac OS formats: A bit more DiskDoubler modes, Compact Pro, PackIt.
• Support for ALZip.
• Probably a lot more that I've forgotten already. A lot of formats have gotten bugfixes and improvements (along with fresh new bugs, no doubt).

At some point I should write a guide to how to write code to support new formats, if anyone else wants to contribute. First I need to get the whole thing working reliably, though. If you're interested, ask me in mail or on IRC or something. It's been designed to make it as easy and painless as possible to implement new formats, though, so if there's something you'd like to try, you should give it a go!

Oh, also, the bug tracker is here:

http://code.google.com/p/theunarchiver/issues/list

Filing reports there makes it less likely that I forget about them, for anthing more complicated.

Some more additions I forgot the first time:

• Much improved 7-zip support, supporting most compression algorithms (but not encryption).
• Improved Tar support thanks to halcyon (http://halcy.de/).
• Support for Deflate64, bzip2, PPMd and LZMA in Zip.
• Support for old-style standalone .lzma archives (but not the new-style ones, yet).
• Support for XAR archives (gzip and bzip2 only, not LZMA yet, needs support for new-style standalone .lzma).
• Improved RPM support.

>>6

That does sound very interesting. PAQ has been pretty useless before, but that could change that.

>>6,7

Unfortunately, though, the example code is GPL and thus not really compatible. It'd have to be implemented from scratch.

Alpha 2 released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0alpha2.zip

• Fixes problem with large files
• Fixes problem with multi-part archives

>>8
yeah, someone really needs to write a free decompressor for it.
maybe i'll do that sometime this summer.

Alpha 3:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0alpha3.zip

• Bug with extracting OS X zips fixed.
• Canceling extraction was broken, should work again.

The NSLock bug (http://wakaba.c3.cx/sup/kareha.pl/1151796773/492) seems to be fixed in 2.0 Alpha 3. If you want to further investigate this issue, here is the archive I used, which triggered the problem in 1.6.1 (http://vim-latex.sourceforge.net/download/latexSuite20060325.tar.gz)

>>8

Or you could simply make two versions of libxad: One licensed in GPL and includes support for ZPAQ and another licensed in LGPL and does not link to the ZPAQ library.

>>13

That's funny, it should still be there, as I haven't touched the interface code much at all yet, and that's where that bug is.

>>14
it's better to write a free version from scratch than to distribute free code under a non-free license.

>>16
GPL and LGPL are free licenses, fucknut.

>>17
He's a license troll.

>>18
Oh IHBT. Damn.

>>17
http://www.charvolant.org/~doug/gpl/html/index.html

proprietary licenses are not free licenses.

>>20
What an incoherent bunch of bullshit.

Disk Doubler 3.0 archives get extracted properly with this, making it the only OS X application that is able to extract these files. Good job.

Will test other archives I have lying around.

I am, by the way, interested in any and all information about the algorithms used in later versions of DiskDoubler (3.7 and 4.0, I think?). Those are not yet supported, but I would very much like to support them.

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0alpha4.zip

• Fixes a permissions error that sometimes made the contents of zip archives invisible to the Finder.

I'd really like to hear how well this works with encrypted and large RAR files, by the way. I only got one confused bug report on the tracker that can't be reproduced. Has anybody tried this, especially on files that didn't use to work?

% dd if=/dev/urandom of=random bs=1024 count=2048
% rar a archive -v512m random

The 512m there should be 512k, of course.

Oh, nevermind. It got fixed in alpha2 and I didn't notice.

Great to see passworded rars finally working!
I have no idea whether it might cause issues, but have you considered, when unarchiving a bunch of archives at the same time, to remember the first password provided by the user for the duration of the unarchiving session, and attempt to use the same password on subsequent protected archives? It would save some time sticking around pasting 20 times the same password for some usage scenarios.

>>28

I guess there should be an "apply to all" checkbox for the password, too.

Rars with password keep failing to extract...

>>31

Which exact version? And once again, I can do nothing about it without some example files.

version: 2.0 alpha 4

>>33

Are you sure it's not actually running an old version you still have left? Also, I still need those files.

I downloaded yesterday... :S

I tried it on 3 movies I downloaded from www.rapidsharemovies.org

Checked again.. The version is 2.0 alpha 4...

still failing to extract password protected rar files

>>35

Give me some specific files to test. I can't read your mind and guess what you have downloaded.

http://www.rapidsharemovies.org/training-day-2001/

I can not untar a big tar package (about 12G) with The unarchiver v1.6.1 or v2.0 alpha 5. This tar file was creative in Windows System by 7zip or Winrar and some file names in the package was encoded by "zh_CN.gbk".

The Unarchiver v1.6.1 can extract part of the tar file (about 2.2G) with right file name encoding, but it report the rest of files are incomplete. But actually, The Gnu tar and other application like Suffix expander can extract all files, but got wrong encoding.

The Unarchiver v2.0 a5 just hang at "preparing to extract" and will not go further.

I wounder could this be a bug ?

Thanks.

>>39

Really huge archives with lots of files are probably not going to work in the current Unarchiver. I've got some ideas about fixing this but it'll probably have to wait until later.

Thanks for quick reply. I'm very glad to here you have ideas about that. :) For me only the Unarchiver can cope with the archives with non-utf8 encoding files. Thanks again!

>>41

2.0 might handle it if you just wait long enough for it to scan the whole file. It might use a whole lot of memory for it, though.

>>38

All right, fixed it so that thing extracts. It takes forever, though, not sure if that's expected or not.

PS RAR is a horrible, horrible format.

Well, I think it's time to upgrade this to a beta release:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0beta1.zip

• Most of the outstanding UI bugfixes and small improvement requests on the issue tracker should be done.
• There's been some general cleanup and re-arranging of the UI code, which may have introduced some new bugs.
• No translations. The updated UI needs to be re-translated, which will happen when I am sure there will be no more changes to it.
• Some fixes to the uncompression engine, like the RAR bug mentioned above.

What's needed now is for people to try out the UI and the new options, as well as the old ones, to see that everything works as it should, or to report any fixes I forgot about.

>> 41

Thanks for the Tips, I have tried the Archiver 2.0 beta1 to extract my 12G tar file. After a long time preparing, it crashed.
I think the tar file is too large for my memory of my laptop.

If necessary, I can send you the error report. Thanks.

Finally PS RAR files can be extracted! Thank U!!!!

Just one thing: could u add an option to never create a new folder for the extracted files?

Thanks again!!!

>>46

Probably not, it would require figuring out how to deal with colliding filenames which I rather wouldn't do.

I am just wondering if xar support is simply implemented using libxar and whether bsd flags, resource forks and extended attributes can be preserved when extracted using The Unarchiver, since the main design goal of xar is to preserve all metadata.

>>48

It is implemented from scratch. Resource forks are handled, but no other extended attributes. Implementing this correctly is a bit of a pain since the xar format is essentially undocumented.

>>48

Also, if you want support for more xar features, supply some files that use them so I can try to figure out how they work.

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0beta2.zip

• More bugfixes.
• Slightly more clever handling of the dock icon (it appears only when starting the program directly).
• Some other stuff I forgot about already.

The GUI is now feature-frozen for v2.0, so that I can start trying to collect translations. Only going to be fixing bugs and doing internal improvements until after 2.0.

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0beta3.zip

• New ARJ parser that actually works.
• Support for the Blend algorithm in sitx files.
• Support for unpacking Nintendo DS .nds files.
• Japanese, German and Portugese translations.
• Bugfixes, of course.

Oh, and for the old Amiga fans, I made the .adf parser work again so you can extract the files on a fastfilesystem .adf file, and also made the libxad DMS code unpack .dms files to .adf (although it seems a bit buggy).

>>50

I am wondering if it would be possible for libxad to link to libxar for handling xar, because libxar has been verified to handle EA, resource forks and more obscure metadata such as BSD flags correctly. I don't think there is any licensing issues with libxar. Reverse engineering is also much more likely to introduce bugs compared to the native implementation.

>>50
The author of this HFS metadata test suite (http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/) tested against xar svn (fix later released in xar 1.5.1) and found it to handle all known HFS metadata correctly. You can simply use this suite to generate sample archives and verify how much metadata is preserved. It would be interesting to see if the Unarchiver's zip, tar, cpio and pax implementations are capable of restoring whatever metadata that's actually preserved by the archiving program.

>>54

If I recall correctly, it libxar is not compatible with how the current XADMaster.framework works.

>>56

I don't have any files with any other metadata than resource forks, and I'm not even sure how to create any. I'd really prefer to have some real-world examples.

>>58

No, probably not. I'll want an example file for that.

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0beta4.zip

• Support for unpacking NSIS installers (extremely tricky to do across multiple versions, but it seems to handle every installer for NSIS itself back to version 1.1o)
• Better support for LZH
• Swedish and Russian translations
• UI bugfixes and other bugfixes

>>57

The backup-bouncer suite I mentioned earlier will generate a source disk image contains files with all types (and combinations) of HFS metadata (EA, resource forks, BSD flags, Finder comments etc.). You can use whatever archive utility you want to archive the generated files and then extract the archive using the unarchiver to a destination disk image, also generated by the test suite. You can then run the bbouncer program to verify the files.

For real world (and non-trivial) usage of extended attributes, you can download Skim.app, which uses EA to store its annotations. The chflags utility (included in OS X) can be used to change the BSD flags of a file.

I will try to send three files:
1) the 7za compressed file
2) screenshot of the .7z file and the extracted folder icon with a "-"
3) screenshot of "Get Info..." of the extracted folder
4) the 7za compression log