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!

Well, after some work, I've finally got this into a state where it is actually just about presentable. It's still an alpha version, and is released mostly because I could really use some large-scale testing, but it should actually be useful.

http://wakaba.c3.cx/releases/mac/TheUnarchiver_alpha_1.zip

Features include:

• Built around libxad (http://sourceforge.net/projects/libxad/). This is an old Amiga library for handling unpacking of archives. It supports a whole lot of formats, and I added a couple more, and bugfixed old code. I also wrote a higher-level Objective-C wrapper around it, which might be useful for other projects too (including Xee).
• Supports more formats than I can remember. Zip, Tar, Gzip, Bzip2, 7-Zip, Rar, LhA, StuffIt, several old Amiga file and disk archives, CAB, LZX, stuff I don't even know what it is.
• Supports split archives for certain formats, like RAR.
• I copied the Finder file-copying/moving/deleting interface for its interface.
• Uses the character set autodetection code from Mozilla to auto-detect the encoding of the filenames in the archives.
• I haven't bothered packaging them yet, but at some point I'll release the source for all this, and also frameworks for linking against the archive and character set autodetection parts, which might be useful in other projects.

Issues:

• The format support is not complete for many formats. Given the complexity and unplanned evolution of most popular archive formats, support will probably never be complete. However, most files should work. Notable exceptions include:

  • No support for encryption in any formats. Libxad supports encryption, but the GUI does not. The RAR and 7-Zip modules do not support encryption at all.
  • No support for fancy RAR features like recovery records.
  • Very basic 7-Zip support (based on the 7zC code). It can open all of the (very few) 7-Zip archives I have, but there are probably archives out there it doesn't support.
  • No support for .sitx files. This format seems completely undocumented and un-reverse-engineered.
• No icons yet. If anyone wants to contribute, I would be very grateful. It needs a program icon, and a set of icons for the huge set of archive formats it supports.
• The error messages should probably be re-written to be more friendly.
• It opens an icon in the dock, unlike BOMArchiveHelper.app. This is very easy to fix, but for the alpha versions, it's easier to keep track of what's happening if the icon is there.

What's needed now is:

• Testing! Try it out on all kinds of archives, see what it handles, and what it chokes on. Send me archives it doesn't handle, and I'll see what I can do about fixing support for them.
• Icons! Are you a Mac icon artists? I want your help!
• Code contribution! Libxad is an awesome library. However, it could always use support for more formats. Is your favourite format not supported, or broken? If you contribute code for it to libxad, it will be supported by The Unarchiver, too!
• Suggestions! Is it missing features not already mentioned here? Suggest them, and I'll give them consideration!

Oh yeah, one more missing feature:

• A preference page, including at least some way to easily make archives open with The Unarchiver, like the format list in Xee.

Is this universal if not then you need to DIE.

It's universal, but I have no idea if it works right on Intel. There might very well be endianness issues in the various pieces of code. I'd especially like to know if the RAR and 7-Zip code works right on Intel, so get testing.

Ok, first obvious bug: Xcode has somehow messed up the framework linking, and this won't launch at all on most machines! Stay tuned for alpha 2!

http://wakaba.c3.cx/releases/mac/TheUnarchiver_alpha_2.zip

All right, fixed! Big thanks to Rich Siegel for untangling my linking issues.

Alpha 3 is done. It is pretty much feature-complete for 1.0. However, it still has no icons. I have some help for that lined up, though, but I don't know how long that will take. In the meantime, for testing purposes, the archive icons are replaced by a picture of Aruruw sitting in a box.

http://wakaba.c3.cx/releases/mac/TheUnarchiver_alpha_3.zip

Changes since the last version include:

• Bugfixed file type declarations.
• Interface for easily associating (and un-associating) archives with The Unarchiver, making it easy to install and remove.
• Working password interface.
• Bugfixes for bzip2 archives.
• Various other bugfixes.

I could really use some testing results from this, successful or not. I'd really like to know if it is working at all for whatever archives you have lying around!

It runs on my Power Mac G4. I am trying to unpack some splitted ace archives that unace on GNU/Linux didn't manage to fix, and it seemed to work in The Unarchiver! I'd like if it had an option to select where to unpack the files to, though.

Oh no, it didn't extract after all. But those archives could be rotten. I'm going to make it my default unarchiver anyway.

>>13

It doesn't support Ace 2, sadly, just Ace 1. Ace 2 is propriatary and undocumented, as far as I know. It really would be nice if somebody would add support for it to libxad, but I think it's beyond my abilities to do.

http://wakaba.c3.cx/releases/mac/TheUnarchiver_alpha_4.zip

An enough-coding-for-tonight release. Features better control over filename encodings, and better fallbacks when the autodetection isn't sure about the encoding.

http://wakaba.c3.cx/releases/mac/TheUnarchiver_alpha_5.zip

Some GUI bugfixes and optimizations, and support for OS X-specific features in .tar and .cpio files (as created by OS X's version of tar, and ditto, respectively).

Repost for great justice.

Uh, the thumbnail doesn't look very good, probably because of something about the way the graphics program exported the PNG, or the way the thumbnail was made. But, uh, if you click on it it the original looks a lot better. At least, it does for me. Sorry about the double post.

When I think of something to open up boxes with, a box cutter comes to mind. Perhaps it could be seen in bad taste, but it seems pretty natural.
I expect that the thumbnail will look bad again, due to the transparent PNG.
Third version adds the background.

adding "-background white -flatten" to the convert command line in wakaba and kareha would probably fix that problem...

The Unarchiver unpacked some of my SHIFT_JIS encoded archives with no problems! I love this application. If it'd only been ported to GTK+-2 as well···

It messes up the filenames on the sit here.

http://micono.hp.infoseek.co.jp/decodingqr/index.html

>>24

Oh yeah, SIT filenames aren't necessarily correct. I should look into that.

Ok, let's call this feature-complete and thus, beta.

http://wakaba.c3.cx/releases/mac/TheUnarchiver_beta_1.zip

Now with icons! Made by Adam Betts, infamous creator of the Adium duck. There's no proper main program icon yet, though, just a placeholder for now. That will come with the final release version, probably. Funnily enough, he also decided on a boxcutter theme for it. Sorry to >>21 for not using his icon, but I'd already talked to Adam at that point about it.

Also, >>24 should be fixed.

I suppose it's my own fault for making them. I could certainly make the cutter look a little bit shinier and aqua-esque... but then, I only spent a day on it. Even if nobody uses it, I kinda like how it turned out, and if Betts uses a cutter, too, then it must have been a pretty good idea.

Me, I never liked the duck. Memorable though it may be. That's right! I'm a-callin' you out, Betts! Dreeeaaw! No, but seriously, I'll be interested to see what a real artist can do with it. And I hope you end up using his icon because it's better, too.

And I hope you come up with a catchier name, by the way. I always kind of assumed that it was a working title, frankly.

I always end up using dumbass titles for programs. I kind of like this one though because of the implication that it's just the unarchiver, as opposed to one out of several. Also "Open With -> The Unarchiver" is pretty clear and descriptive.

It's a bit ungooglable unless you include the "The", though.

If anyone has a catchier name for it, I will definitely consider it, though.

"rip it open"?

Speaking of box cutters, there's a multipurpose box- and blister-pack opener tool call "OpenX", which also happens to be a great potential name for The Unarchiver. Maybe it'd be possible to get a permanent license from those guys to use both the name and a picture of the tool. Free publicity for them, catchy name and nice icon for the product. ;-)

http://www.myopenx.com/

I wouldn't do it for anything less than permanent licensing, or for more than the cost of a simple reciprocal link to their homepage. But it's a thought.

That tool would be a little too complex for 128x128 icon, people will have a hard time figuring it out. What I'm going to do is make a very basic box cutter so it will scale very well. 32x32 is around the size everyone will see a lot. I don't have time to do them right now but soon I will.

By the way, here's a mockup of The Unarchiver window in black HUD. I know author said he doesn't want to do it since it's not easy to do but my friend Jan Van Boghout is willing to do it if he have the source code.

Beautiful window like this will definitely get a lot more people to download The Unarchiver :)

A random thought popped into my head: Since the theme for the icons is packages and opening them, would "The Unpacker" be a better name, or not? More or less recognizable? More or less Googlable? More or less cheesy?

When I read that, I only saw: "The Fudgepacker"

I've been spending too much time on /b/.

Unarchiver is at least one syllable too long. I've actually been calling it Unpacker every time I saw it...

Also, black is kinda neat, but frankly I'm against it until you at least have the standard set of buttons on that window, sir. Which would be easy enough to fix, I guess.

But there are ways to change how OS X looks, and it seems like somebody who wants black windows might already have done that to their system... at which point, the Unpacker is just going to stand out as different, right? I know I'm just a fuddy-duddy, but I like my user interfaces standard. Apple has been doing a very bad job with that recently, but that doesn't mean we all have to jump off the bridge.

That black HUD window is actually the newest standard. You can find it in Apple's iPhoto, Aperture, Motion, etc.

More and more developers are using it for palettes/window that doesn't need full white space.

It's not about me wanting a black window just for the sake of it, it's excellent for usability since it's light weight with transparency and has flat look which look much more professional and stay out of your face.

Hopefully Apple will add a public API to use that style. That'd make it an easy change.

But I fear that might not be until 10.5, if at all.

do you distibute source of?

I was meaning to release the source at the same time as the final version, since development is not in a very stable state until then, but if you really want it, I can upload a copy of it before that, too.

New version with some bugfixes:

http://wakaba.c3.cx/releases/mac/TheUnarchiver_beta_2.zip

• Fixes problems with directory structures in Japanese archives.
• Fixes problems with data forks in some StuffIt files.

Thank you SO GODDAMN MUCH

> That black HUD window is actually the newest standard.

Brushed Metal is gonna be so pissed

> Brushed Metal is gonna be so pissed

Brushed Metal is so ugly!

Any updates?

I hope WAHa doesn't mind me pasting this:

< WAHa_06x36> onii-chan: I've had The Unarchiver in beta 
for MONTHS now, and I haven't gotten a single bug report 
except from MrVacBob, and that one has a much larger 
possible user base.

If you want updates, maybe submitting a bug report or two would make him happy?

At this point I am mainly waiting for a final icon (I should probably kick Adam's ass a bit), and in the meanwhile any final theoretical bug reports.

Well, since there haven't been any bug reports, I guess I'll just call this done and release v1.0.

http://wakaba.c3.cx/releases/mac/TheUnarchiver1.0.zip
http://wakaba.c3.cx/releases/mac/TheUnarchiver1.0_src.zip
http://wakaba.c3.cx/s/apps/unarchiver.html

Hi.

Nice idea. I'm going to try it as an alternative to allume's bloatware!

I'll post as I find issues, but here's one right away. It doesn't play well with .sitx files.

Cheers

Calvin

Ooops! Found it.

Sorry, I was reading the latest posts only, not the full thread.

I tried beta version, everthing seemed fine except that "File name encoding" didn't work. I couldn't read it in the advanced menu of the preferences. Just lines of the strange characters in the menu...

As for the version 1.0, I couldn't even start it.
I tried to throw away the old preference file, but I couldn't find it.
No way.

My enviroment is OS 10.4.7.
I use my Mac in Japanese, English and French.

Anyway, I appreciate your work.
Thanks

>>49

Can you open Console.app and see if it lists any error message from The Unarchiver?

Yes, I tried.
But there is nothing in the log.
I erased the log before I opened the unarchiver.

This time, the preference window is opened.
But the application menu didn't appear. No application icon in the Doc.
I had to open the activity monitor to quit it.

I've never seen things like that!

>>51

It is set up to not use an icon when it opens archives, just like BOMArchiveHelper.app. However, this means it also doesn't show an icon when you open the preferences window. However, you can quit it by just closing the window.

Normally, you don't open the program directly, you just let the operating system open archives using it. (Again, like BOMArchiveHelper does.)

OK, so it's a normal behaviour.
For the file name encoding, I choose "Ditect automatically".
But other choices are unreadable.
Is it normal, or do you know a solution?

>>53

It's probably a bug in the program. The way the program has to get this list is kind of strange, and I probably got the code wrong somewhere along the line. You usually do not need the list, so it's not a big problem. I'll try to fix it for the next version.

How can I choose not to "mkdir" when it unarchieves?
Sometimes it get many unnecessary folders.

It crashes on start up. Does it require Tiger?

I tried it on the tbz file for my plus and minus icons, and it didn't do anything: it simply showed me the “Preparing to extract “plusminus-1.0.tbz”” dialog. Clicking Cancel does nothing but disable the cancel button. I must force-quit the app to get it to stop its barber pole. Nothing is written to console.log.

Regarding the icon: I love it. ☺

>>55

There's no option for it, but it should not create a new diretory if there is only a single base directory in the archive. If you are getting several single directories inside each other, it's probably because that's how the archive is stored.

>>56

I haven't checked, but it probably does.

>>57

I can't find the .tbz file on that site. If you have it, mail it to me.

Thanks, another really needed app like Xee :).
Seems to work fine until now here on OS 10.4.7 PPC, but it didn't associate itself to archive file types although I selected all file types in its preferences. I suppose I should associate them manually, but I'll wait because it lacks one feature important to me: choosing a default unarchive destination.
As far as I can see, it currently unarchives files in the same folder where the archive resides, while I prefer unarchiving them on my desktop. Is it a planned feature for the future?

>>59

The OS X API for associating with filetypes is still kind of broken. Also, if you're using a Mozilla-based browser, the browser has this super-annoying behaviour where it will set a filetype and creator on the files it downloads, but will NOT get the right one. It's a reported bug, I've tried voting for it and mentioning it needs to be fixed, but nobody cares.

If that turns out to be your problem (if, say, files downloaded through other means open in The Unarchiver but files downloaded in Firefox or Camino open in something else), go vote for and post in https://bugzilla.mozilla.org/show_bug.cgi?id=236389.

A default unarchive destination was not something I planned but it would be easy enough to do if I just stuff it in the advanced preferences, so I guess I'll look into that for 1.1.

can't unzip archives with password protection :(

can't unzip archives with password protection :(

The latest archive of MacTranslator (testet with 0.10 and 0.11) from http://sourceforge.net/projects/mactranslator will produce a checksum error on decompression, whereas BOMArchiverHelper.app will do just fine. If you do the decompression in PathFinder instead of Finder, The Unarchiver will not even display the dialog box containing the error. This freezes The Unarchiver and leaves no option to decompress any more archives.

I assume both of the described problems are bugs?

>>62

You can extract some of them. However, there are many kinds of password-protected zip files. Send me the file and password and I will look into it.

>>63

That's funny, I got another similar report, and that one failed on the exact same file in another archive! This is kind of funny.

The second sort of sounds like a bug in PathFinder, but I am largely unfamiliar with it. Does Console.app list any errors?

If it does require Tiger, you should state that on the page.

Thanks.

>>63

I just fixed this.

Cool app, but are there future-plans to support also compressing and not "only" uncompressing?

Would be great to have the PopUp-Window if you right-click on files/folders and don't have to choose only the Apple-implementation of .zip-archive but also from your application and the choice of .rar, .7z and so on…

PS: I know, the name of the application is "Unarchiver", so maybe we need a new name also to satisfy my wish… ;-)