So. I kind of like BOMArchiverHelper.app, the default OS X unzipping utility. However, it has quite a number of limitations. Most other unarchivers on OS X have interfaces that I don't like, or just don't work very well. Also, thanks to Windows' idiotic idea of using the current system encoding for filenames, I have tons of archives from Japan with Shift_JIS filenames, which none of the unarchivers on OS X I've tried will handle properly.

And so I, because I obviously don't have enough to do already, get the idea that I need to write a better unarchiver. Features I think it needs include:

• Handle as many formats as possible. Not just Zip and Tar-Gzip, but RAR, 7-Zip, LhA, StuffIt, and anything else you can think of.
• Handle non-UTF8 filenames, perferrably automatically.
• Have a simple and straightforward interface like BOMArchiveHelper.app.
• Not leave .tar files lying around when unpacking .tar.gz files and the like.
• As a side benefit, produce some code that can be re-used to add archive support to Xee (so this whole project doesn't just steal time I could be working on Xee instead).

For actual information on the current state of this project, read on!

Fantastic! So glad to see support for encrypted RARs!

Can we have an option of Never create a new folder for extracted files?
Thanks!

>>602

Probably not, it would require me to create all kinds of code to handle file collisions gracefully and I am too lazy for that.

big thank you to the developer, now i can finally move away unrarx. this is simply the best app for extracting files now

>>597
You are right. It was from Simple Comic. My bad, got the two confused.

>>606

Any window that does not have a dock icon will act that way. There seems to be no way around it. It tries to jump to front if it needs your attention.

Great work, finally 2.0 can handle passwort protected RARs!
But unfortunately the window always gets itself behind automatically before I can enter the passwort, that is very annoying and it also takes 3-4times longer than with other app such as Betterzip, so maybe you can improve the speed as well.

Great work, finally 2.0 can handle passwort protected RARs!
But unfortunately the window always gets itself behind automatically before I can enter the passwort, that is very annoying and it also takes 3-4times longer than with other app such as Betterzip, so maybe you can improve the speed as well.

Great work, finally 2.0 can handle passwort protected RARs!
But unfortunately the window always gets itself behind automatically before I can enter the passwort, that is very annoying and decompressing also takes 3-4 times longer than with other apps such as Betterzip, so maybe you can improve the speed as well.

I'm having an issue with The Unarchiver 2.0 regarding extraction of encrypted multi-part RARs. They extract fine, but take way too long to do so. I am doing this a lot lately, so it's not just one multi-part RAR that's having trouble, it's every one I try.

I'll give you an example... a recent mutli-part RAR I extracted using The Unarchiver 2.0 took about 3 hours to do. The same multi-part RAR extracted using UnRarX in less than 20 minutes.

Not sure what's going on here, or what I can specifically provide to help. I would love The Unarchiver to by my sole utility for extracting compressed files, but with this problem it's honestly unusable to me for this purpose.

Version 2.0.1 released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0.1.zip

This is a minor bugfix release.

• Should now handle concaternated bzip2 files.
• Fixes to the Japanese translation.
• Fixes to the LZMA parser.

>>608.611

Looking into the speed issues.

Have you considered something like Sparkle autoupdates for The Unarchiver?

I would love to see Sparkle added for Auto Updates for sure

64 Bit for Snow Leopard Would be nice too,

http://developer.apple.com/MacOsX/64bit.html

>>616

The library will be updated to support 64 bit at some point soon, so it can be used properly by other apps, but I'm not sure if there's any real need for the app itself to be 64 bit.

Version 2.0.2 released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0.2.zip

This is another minor bugfix release.

• The RAR speed issues mentioned above should be much better now.
• Fixed some issues with resource forks in .tar.gz and .tar.bz2 files.

How does the unarchiver handle files while decompressing? I was uncompressing a large 4 GB multi segment RAR when my computer froze and I had to restart it. Now I think I lost a bit of space on my hard drive but I can't find the file(s).

>>620

They are written to a hidden (starting with a dot) directory in the same place the unarchived files will be while unpacking. 2.0 should keep track of directories it has created, and will delete them the next time you start it if it crashed midway. 1.6.1 does not do that, and you have to remove it manually.

WOW! Thanks for the update fixing the RAR extraction speed... it's now even faster than UnRarX! Now The Unarchiver can serve all my purposes!

Hi, Unarchiver seems to try to auto extract every rar file as soon as its downloaded, is there a way to stop it doing this?

>>623

That's your web browser's doing.

I quickly skimmed through the last fifty or so posts and didn't see any mention of this so I hope I'm not reposting:

When I try to open a large number of compressed files all in one go, it seems only four or five of which will actually be queued for extraction in the unarchiver.

>>625

That's strange. If you can file a bug at http://code.google.com/p/theunarchiver/issues/list with a bit more information I'll definitely look into it.

Isn't there a way to stop the app from creating a folder when extracting?

No.

Version 2.0.3 released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.0.3.zip

More bugfixes and speedups, for RAR again. This format is quite a chore.

>>629
Thanks for the hard work, Waha.
RAR is a bitch, but its still insanely popular for some reason.

2.0.3 is giving me "Error on decrunching" while extracting multi-part RAR on Snow Leopard. Has anyone else had this error?

>>632

Post files that have the error, or I can't fix it.

>>633

Well ummm I don't think it would be good idea since it's an episode from a TV show and it weighs in at ~200Mb.

>>634

Well, then it will remain broken.

2.0.3 is giving me "Error on decrunching" while extracting rar files password.

>>636

Read above.

Here's a file that's giving me "Error on decrunching" on 10.6.1, Unarchiver version is 2.0.3.

http://rs535tg2.rapidshare.com/files/209615230/MI1.rar

Password is:

hostel

>>638

That's more like it, thanks!

>>638

Also, bug found and fixed.

Is there a way to prevent 'The Unarchiver' from taking focus when it opens? I have it decompressing my downloads, and whenever a download completes it comes to the front and I lose whatever I was typing.

I would ditto post 641. It would be preferrable to see the unarchiver appear in the dock and then dissapear when it is done decompressing. A dock icon badge that shows the status of the unzip would be nice although not essential.

Unarchiver needs to stop popping into the foreground.

>>641-642

Then others will complain that it is hiding behind their other apps and they can't find it.

Sorry, I think I wasn't detailed enough in my first question/request. I didn't mean to say it should pop up in the background necessarily, but that it should respect normal focus rules and not automatically take focus. As it is I'm have it launched from the 'command line' (launchd) to handle downloaded archives using the command 'open -a 'The Unarchiver' --background <downloaded file>' and it still takes focus when it extracts archives. So, I will renew my plea a final time, could we at least consider a preference?

Regardless, thank you for your fantastic app. Since I found it I've never looked back.

Sorry again, 'As it is I'm having it' or 'As it is I have it'!

>>640

so, uh... about this fix..??

>>644

Apps without a dock icon do not follow normal focus rules in the first place, is the main problem. I have to take focus, or else The Unarchiver might open up underneath other apps.

>>647

Ah yes, of course, that makes sense. Didn't occur to me at all. Sorry to harangue you about this, but why doesn't The Unarchiver have a presence in the dock? I'm sure there's a good reason, but it's not clear to me at the moment.

>>648

Mostly to make it act like the original BOMArchiveHelper, which didn't have one either. But apparently newer versions do have an icon, so I'm not really sure if it should stay this way. However, some people seem to like it not having an icon.

I always get an error on decrunching for all large multi part Rars, I have 47 part Rar (.rar - r45) with all parts being 50 MB except the last which is 48.2 MB
It seems that if there is more than a certain number of parts it doesn't work, I know 24 50 MB parts work fine
So somewhere in between there it breaks

>>650

Once again, without the files, I can't do a thing about it.

>>649

That makes sense, thanks for putting up with the grilling. My vote, of course, is for the app to mimic the newer versions of BOMArchiveHelper. Thanks again for this plucky little app.

Hi it would be really helpful if when unarchiving multi-RAR files that when you get a corruption error that it is specific explaining which part is corrupt.

Thanks

Version 2.1 has been released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.1.zip

• Added a service for unarchiving files via the the Services menu, or when right-clicking files.
• Some interface tweaks (File menu now works in the preferences window, doesn't ask for destination directories for every archive, archives are not added to the queue twice).
• Proper quarantine propagation for downloaded files.
• Better support for very large Zip and 7-zip files.
• More RAR bugfixes.
• For programmers: The XADMaster library can now be compiled in 64 bit mode, but the The Unarchiver app itself is still only 32 bit.

Hello.
I would like to suggest feature for zip archive file.
Windows Winzip or other Unicode support zip application try to reserve maximum compatibility with legacy zip archive file.
So when Winzip make archive file in particular locale windows, it use specific codepage filename and Unicode same time. If filename can be encoded into windows related codepage( such as CP949 CP936...), it use these codepage.
But if filename can't be converted into local codepage, Winzip use Unicode filename.

As a result, archive file has local codepage filename and Unicode filename in UTF-8.
Fortunately, when Unicode filename is used, 11th bit of general purpose bit flag is set.
We can classify these two different encoding.

Currently in The Unarchiver, it might not aware of this difference. So when I designated specific filename encoding, it will try to extract only one encoding which I gave.

So I would like you to add feature that recognize zip format's 11th bit of general purpose flag. You can found these info. on PKWARE's AppNote.

http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Sincerely
trip2me

>>655

If you can supply an archive that uses this, I will certainly look into adding support for that.

>>656

Thanks for your quick response.

I attached sample archive files.
It includes ascii only filename and Unicode filename also.
They are compressed with some kind of zip application.
There are differences between result of compressed files.
But they conform a 11th bit of general purpose flag to store Unicode filename in local header and central header. You might find easily this flag in archiver file by searching local file header signature (0x04034b50) and central file header signature(0x02014b50).

So if 'The Unarchiver' detects 11th bit in zip file entry, it will extract in Unicode filename even though user already selects specific encoding.

In addition, Winzip implements Info-ZIP's Unicode Path Extra Field in ascii filename entry also. This might be helpful for additional info, not mandatory thing. I mean it's a just references.

I have to say thank you for making wonderful program again!

>>658

It seems the file didn't make it for some reason.

You could try mailing it to me, there is a mailto link on http://wakaba.c3.cx/.

With the new 2.03 - 2.1 version, I obtain "Error in decrunching" with the CAB archives downloaded from TomTom Site.
If I choice "Continue", the extracted files have Zero byte dimension.

My S.O. Mac OS X 10.5.8 Leopard

>>660

Do they work with 1.6.1? 2.0 and later should extract the same CAB files, but there are ones that all versions fail at.

Hi,
Is it possible when you have multiple zip file (as file01.zip, file02.zip, ...) to not create a folder for each zip file but merge all extracted content to the same folder (eg same as original) ?

Many Thanks for this great application.
Kind Regards

>>662

No.

Odd.

"The content of the file may not be extractyed with this program"

I tried extracting some .cbr files with no problems, and some other .cbr files doesnt work. Strangely enough, they may be extracted by other tools I used so I know the files arent corrupted.

Any thoughts?

>>664

Without the actual files there is nothing I can do about it.

>>626

Sorry for not following up but I can't figure out what's causing it. Right now, I have three RAR files that even when renamed to 1.rar, 2.rar and 3.rar, only the first two will be opened and be extracted by The Unarchiver. And 2.rar always opens before 1.rar

If I open these files one by one or even open the missed archive again by itself while Unarchiver is still extracting 2.rar, it gets added to the queue. I'm sorry but I'm not hot on sending you the actual RAR files so you'll have to go with this vague field report.

>>666

Are you using the latest version?

>>667
Yes, version 2.1 on PSX 10.6.1, 32 bit mode.

I'm willing to run a debug version with lots of console messages, just not willing to send you the actual files.

Version 2.1 is finally fast. The only thing that still bugs is that the windows still goes in the background after opening a file. This is especially annoying with password protected archives as you have to find the windows again to enter the password.

Unarchiver seems to have trouble understanding some .7z files. The ones I have had trouble opening were encode with Compress (which can open the files just fine). File size does not seem to be an issue. A 600MB+ file opens fine, but even small files I have compressed myself do not open. I dont know what flags if any that Compress is passing along to p7zip, but its something that Unarchiver doesnt like. Ive attached a file that also gives an encoding error when attempting to un-7zip
Version 2.1 on 10.6.1

This zip file is about 4GB in the system that I recently zip with Unarchiver. But I found that when the time I tried the extract it, it came out this message. That made me to use the Archive Utility on Mac OS X Snow Leopard.

Anny help will be appreciated.

Thanks for the great work as always.

There is a bug on line 109 of XADArchive.m in -initWithData:delegate:error:. It says if(!parser), but it should be if(parser) instead. As it is, none of the -initWithData:… methods work. The same code is repeated, sans bug, in -initWithArchive:entry:delegate:error: and -initWithFile:delegate:error:.

These could also be refactored to be wrappers around a method like -initWithHandle:… to remove the duplication.

Works perfectly on Tiger 10.4.11 PPC to unpack an .EXE file. Thank you!

Works perfectly on Tiger 10.4.11 PowerPC to unpack a non-Zip-format .EXE file. Thank you!

Are you working on DiskDoubler unarchive?

I have some files that will not open with TheUnarchiver,
I can send if you need.

>>675

I have been studying it a bit, but I'd need a lot of spare time to actually figure out how it works. Hopefully I will find the time sooner or later, because I really do want to support it fully.

And test case files are always very welcome. There are a couple of algorithms I do not have examples files for.

>>676

> And test case files are always very welcome

I have mostly photos (tiff) and Quark files that have been DD'd.

Attached is one of each.

>>676
It seems DiskDoubler has 5 formats AD1 AD2 DD1 DD2 DD3
Would you like a file compressed in each format?
If yes, what type of file? tiff, text...

>>678

Actually, I've managed to find that version and make my own examples. However, there are two or three more formats that were used by earlier versions but that can only be unpacked with later versions. Those would be the most useful, but might be very hard to get a hold of.

The Unarchiver seems to have a problem with the Amiga .lzx archives that are using the highest possible compression. The Unarchiver refuses to uncompress such archives. Archives compressed with a lower compression unpack well with The Unarchiver.

I've tested this by making such problematic archives using an Amiga Emulator (I've came across this problem while checking some old archives from my real Amiga 1200) using the last amiga version of lzx that came out:
http://xavprods.free.fr/lzx/
http://aminet.net/package/util/arc/lzx121r1

I was only able to unpack the mentioned archives on my mac by compiling the unlzx source code (from the lzx page or the wiki page below).
http://en.wikipedia.org/wiki/LZX_(algorithm)

>>680

I haven't gotten around to updating the LZX code yet, so it still runs on the old libxad code that I am not very familiar with. Sooner or later I hope to change that, though.

It would help a lot if you filed a bug on the bug tracker and attached a sample file or two.

OK, I will do that soon when I'm home.

great work! i can finally unpack my amiga powerpacker files! you're god. hjsplit segmented files (001,002) and dmg files support would make betterzip and iarchiver useless for me. but what more can you ask for?

thanks !WAHa.06x36!

2.2 is released:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.2.zip

• Korean and Traditional Chinese translations.
• Support for the XZ compression format, along with support for embedded XZ in RPM and XAR files.
• Support for LZMA2 and some more filters in 7-zip.
• Support for NSA and SAR.
• Better support for unicode in Zip files, and some bugfixes for Korean.
• Better support for MacBinary in Zip.
• Fixed an issue where the final file in a Zip file created on OS X might get lost.
• More robust reading of gzip files.
• Fixed an issue with the interface, where the window was sometimes left open.

Love it, works perfectly. Thank you!

>>685

I could do the work to figure out what the dates are and fill them in, or I could work on the actual code. I don't think the dates have very high priority.

I would be nice if in Preferences > File formats there was a button to activate all formats that are NOT supported by the Archive Utility according to its Info.plist (that is, letting Archive Utility handle the formats it thinks it supports, and using The Unarchiver for everything else).

I'm having a strange issue, i'm extracting the files, and when i look at my left over space on the drive it counts down after the extraction, but the output files are no where to be seen.

Where did you configure it to put unpacked files?

I just tried to uncompress a segmented RAR file, but instead of

• foo.rar
• foo.r01
• foo.r02

the numbering goes

• foo.01.rar
• foo.02.rar
• foo.03.ror

WinRAR over in peeceeland handles the segmented archive just fine. TheUnarchiver gets to the end of foo.01.rar and spits the dummy.

Could we please have this growing-more-common segment numbering method in a future release?

(I also second the call for split 001 002 etc files!)

>>692

Because of the way it's built, it's not easy to avoid opening files. I wonder if there's some way to increase OPEN_MAX for a process...

static int setOpenmax(rlim_t limit)
{
struct rlimit rl;
int status;

rl.rlim_max = RLIM_INFINITY;
rl.rlim_cur = ( limit < RLIM_INFINITY) ? limit : RLIM_INFINITY ;
if ((status = setrlimit(RLIMIT_NOFILE, &rl)) == -1) {
if (getrlimit(RLIMIT_NOFILE, &rl) == -1)
NSLog(@"getrlimit: NOFILE");
rl.rlim_cur = rl.rlim_max;
if (setrlimit(RLIMIT_NOFILE, &rl) == -1)
NSLog(@"setrlimit: NOFILE");
}
return status;
}

int main(int argc,const char **argv)
{
rlim_t limit = ( OPEN_MAX < RLIM_INFINITY) ? OPEN_MAX : RLIM_INFINITY;
if (setOpenmax( limit ) == -1)
NSLog(@"Failed to change OPEN_MAX");

...continues...

#include ( sys/resource.h ) /* for setrlimit, getrlimit */
#include ( sys/syslimits.h ) /* for OPEN_MAX */

>>694

Interesting. I will have a closer look when I get back to work on the next version.

Once I download Filezilla from its website, The Unarchiver decompresses it in a weird manner, which creates "FileZilla_3.3.1_i686-apple-darwin9.app" instead of "FileZilla.app."
The strange file is even not executable, only showing an error message.
While Mac OS X Archive Utility does the job correctly, The Unarchiver keeps the same problem even after some bug fixes and version 2.2 still fumbles.
Please check this out. You can download the Filezilla file in BZ2 format at following link.

https://www.ohloh.net/projects/filezilla/download?filename=FileZilla_3.3.1_i686-apple-darwin9.app.tar.bz2

>>698

That link does not seem to work. It just goes to a download page that does not have that version listed.

http://pqrs.org/macosx/keyremap4macbook/files/KeyRemap4MacBook-5.1.0.pkg.tar.gz did not unarchive properly for me with latest version (2.2). It appeared to work but the resulting file gave an error when opened.

Built-in Leopard archive utility was successful. I'm on 10.5.8

Thanks.