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!

>>100

Could you do one more thing? Extract an archive to get an empty folder, and then open up the Terminal, cd into that directory, and run ls -la there?

I get this:

simon-wolfs-computer:~/Desktop/DevCon2006 Simon$ ls -la
total 0
drwxr-xr-x 2 Simon Simon 68 Jun 1 11:40 .
drwx------ 14 Simon Simon 476 Sep 23 00:51 ..

I have also had a situation where extracting a SIT file results in a directory being created but it being invisible to Finder. The logs have the same error message for this. Creating a new directory to force a refresh didn't help.

>>102

Does the extraction progress window show up at all? Does it show any of the names of files it is supposed to extract?

An extraction window flashes up very, very briefly so I cannot see what it is reporting.

Minor problem I'm having with 1.1:
The icons for some files are not showing up. For example, .zip (which is associated to Unarchiver) shows up as the unknown document icon (blank page) instead of the nice brown package icon. Works fine for others (RAR, for example).

Any thoughts?

Thanks for this app, it's soooo much nicer than StuffIt.

I should add that I have the same problem as Nick with my SIT files.

>>105-106

Is this for files downloaded with Camino/Firefox, or some other browser?

I'm using Safari. I will try to find a .zip from somewhere other than Safari.

I'm using OnniWeb 5.5.

Seems to be happening on all zip's regardless of where they came from. Tried rebooting, did nothing. .sit icons work fine though.

May have found a fix...

Find a file of the type that is not getting the correct icon (Simon, in your case a .sit).
Get Info on that file, and go to the Opens With... section.
Change it from The Unarchiver to anything else that can open it.
Hit the Change All... button. The icon should change to the new apps icon.
Now go back to the drop down list and change it back to The Unarchiver, and hit Change All... again.

Worked for me.

Thanks Nick. When I changed it to another application the icon stayed blank but then changing it back to The unarchiver sorted it out.

I am tempted to blame Apple's kind of broken UTI handling for that one.

>>93
>>94

hi again, no info on the console.
the hardware is an iMac intel core duo 1.83 ghz with 1.5 Gb ram; os x 10.4.7

hope this helps...

I have a funny feeling that this is a 10.4.7 issue too since it is not just The Unarchiver that seems to be affected. Roll on 10.4.8!

No errors on the console? That makes it more mysterious again.

The last thing you want is a mysterious bug. Sigh.

Hi

Found a bug in the SIT extraction process of unarchiver.
Look at the driver for the Roland RD700SX Stagepiano http://www.rolandmusik.de/ftp/pub/downloads/tecfiles/P_bis_U/OSX_Treiber/RD700sx_drv_OSXi.sit
You will find a difference if you extract it with Stuffit Expander or The Unarchiver.
Hope you can fix it :)

To help with the empty folders.

Try "Create New Folder" INSIDE the empty folder, or move (and move back later) a small file to the empty folder. Doing this should update the folder and suddenly make all the folder contents visible.

Note: apparently there is a way to fix this (not tested by moi) in the preferences in StuffIt Expander. I heard that unchecking the "Set Execute Permissions by Default" will solve this little bug. Give it a try and see if it works.

Hiko, I'd already tried this solution but it doesn't work for me. In fact the extract process doesn't actually appear to work so I simply end up with an empty folder.

Anyway, it may help others I guess.

I think you should offer a solution kinda like Filecutter has.

http://img209.imageshack.us/img209/9479/bild1in0.png

Where you can choose an "Upload to..." option and possibly some other options too.

That would IMO be a BIG ADDITION to this excellent app!

Thank you so far :)

I really like The Unarchiver because it is simple and fits in with the rest of OS X. It would be really nice if the developer would keep it that way instead of piling options upon options (an extraction tool should be very simple) or adding UI that won't fit with the rest of the system (unfortunately, Apple has a habit of doing just that...)

Instead, it would be really nice if the developer could focus on supporting more features from each format. It is probably quite easy to add better support for the 7z format since portable source code is already available from the p7zip project. Personally, I don't support proprietary formats like sitx and haven't seen any software distributed in that format. I think the developer should focus on formats that are more cross-platform and open instead of a closed format like sitx.

>>121

Hmm, I've actually never seen a Mac app do that. It might not a be bad idea if I can figure out how to do it, and find some time to do it.

>>122

The 7-zip code is, unfortunately, quite horrible. When I started out, I was considering using it, because it can extract a lot of formats, but I found it very badly designed, full of Windows-isms, and completely undocumented and uncommented. Well, I am guilty of that last part myself, so I can't really blame the author for that, but it did mean the code was unusable.

Right now I am using the 7z-C code from 7-zip, which is a separate implementation in plain C instead of Windows C++, which is much easier to use, but not as capable.

I agree with >>122, the app should stay simple and not add extra features like the items in >>121.

My two requests:

Concatenate 001, 002, 003 (et cetera) files back into a single archive.

Process PAR/PAR2 files for file recovery.

Also, a request for further down the road: A dock icon, perhaps invoked when you have an archive or collection of files (e.g., a RAR set) that is over a certain size. As it stands now, it's a bit annoying to have to keep re-finding the extraction dialog buried under tons of windows (since it doesn't show in the dock or cmd+tab).

Even with these few things, The Unarchiver is amazingly sweet. Thanks so much!

>>124

There is no way to switch the dock icon behaviour that I know of. Either an app has one all the time, or never.

Multi-part archives are already supported, but this is only triggered for certain naming schemes, such as ".r01/.r02" and "part01.rar/part02.rar" for RAR. If you have files with another naming scheme, give me some example files and it should probably be easy to add support.

PAR/PAR2 has been requested, but I don't know much about it, so it would take some time to implement it. Unfortunately I don't have much time at the moment between all my projects, so I'd really appreciate it someone wanted to help out with this.

(For anyone interested in helping out with this: libxad reads data through a custom callback handler, that implements open/read/seek/close functionality. Multi-part archives are handled transparently through this, for instance. A PAR/PAR2 handler could be written that works like the multi-archive handler but additionally fills in any missing pieces by itself.)

122 & 124

If you dont want the option to extract to a certain folder the simply dont install the finder plugin, if you are not used to e.g. WinRar on windows which has the Extract to.. option.
If you have you are pretty dependent on that, eg. when unararing huge archives > 1gb you want to extract to another physical drive to get a huge speed increase, and that is unfortuneatly not very easy with thuis application atm. You can set a drive as the drive to always unpack to, but when the archive is on that drive it unpacks to the same drive and you loose the aformentioned speed increase.

So !WAHa.06x36 i think you should really look into offering a "Filecutter-like-interface" for using an Extract to... option. If I recall correctly it was just a simple plugin file that you copyed into /Library/Contextual Menu Items/ or something.

That would be kinda the optimal solution cause the people that easily want the option can just copy the file and those who obviously dont just simply ignore that option.

Thanks alot once again for this neat app!

I have checked "delete file after unzip" in the preferences (something to the deletion of the file after being unzipped), but the thing is if it's a 2-part file, it throws the first file into the trash (part 1) and not part 2. Just something you could fix. Great app. Great work :D

>>127

Yes, I know, it'll be fixed in the next version.

Would it be at all possible to add an ETA/estimated finish time to the window?

>>129 Like those are ever accurate anyway.

Right, since it would likely be inaccurate, and is very seldom longer than a minute or two anyway, it seems like it would just be a distraction.

!WAHa:

Have you considered adding support to view the contents of compressed files? I don't think much would be needed, nothing like Finder navigation, but maybe the option to see the contents (maybe if a modifier key is pressed) and extract only one file?

>>132

No. I used to run Windows, where every unarchiver worked like this, and I was always impressed with the minimalist functionalism of Apple's standard unarchiver in comparison to that usability mess. The cases where it would be useful to have this are so few in comparison to the common case that it doesn't really justify the code bloat, and the work for me.

However, if someone wanted to make an unarchiver app like this, I should point out that the libxad engine from The Unarchiver is built as a separate framework, and is very easy to use from any program.

!WAHa.06x36:

I'm with you in the UI, keep it non-existent. The way you've implemented it is superb. Fix that arc hive deletion bug and maybe implement Par2, and it's utterly perfect.

Keep up the good work.

>>93
>>94
>>115

Hello again, I've tried again to use unarchiver on my other computer, a G4 macmini, working on the same sit files (Nikon software) that I couldnt un-sit on my iMac intel and guess what ?... it works !!! It seems that (at least for me) unarchiver works ok for sit files if you use a powerpc, it doesnt on an intel machine.

Hope it helps.

>>139

I suspected as much. I am hoping to get an Intel Mac soon, though, and then I'll be able to test it myself, hopefully.

Archive:
http://dub.washington.edu/projects/denim/download/mac/download_alone.shtml

doesn't extract properly in Unarchiver, but does in Stuffit 9. It's hqx.

(unarchiver is great anyway :)

It extracts fine here. Are you using an Intel machine?

First of all, thank you very much for this app.

Having to use stuffit was one of the major blemishes on my wonderful mac user experience and I'm sure many feel the same.

Don't know if this is Intel chip-related but when I unarchive Japanese files with Japanese encoding, even if I set the confidence level to 100%, it still asks me for confirmation whereas on my PPC iBook it never does and I have it set at 80% as recommended.

>>143

Ah, you probably misunderstood that option. Setting it higher means it will ask more often, because it sets the level of confidence the program needs before proceeding without asking.

However, if there are any files where it asks one one machine but not the other when the confidence level is set the same on both, then that's a bug, and I'd appreciate it if you sent me the file to test.

As Stuffit 11 now lost the contextual menu feature I used most of the day, I wonder if TU can be made to list archive contents in a contextual menu.

Even nicer would be to extract just a selected file from the archive.

Thanks, TU looks very promising.

The latest patch for Sim City 4, in sitx format, doesn't extract at all with The Unarchiver (1.1)...

Nice program otherwise.

SITX is not supported.

Extracting 7z files sets modified of all extracted files to "now", extracting with 7zx works.

>>148

The 7zC code used by The Unarchiver does not provide the date. I've asked the author to fix it, but I don't think he has, yet.

My comment (127) I talked about the autodelete when there has been an extraction of a format. Is it possible for you to get this working in pathfinder? It doesn't delete at all in pathfinder. Can't wait for the next version!

>>150

That sounds more like a Pathfinder bug. Maybe you should try reporting it to them?

Thanks for this great software. With Xee and The Unarchiver you gave us 2 of the most wanted and needed software on mac. I can't understand why nobody did it before, because it's so obvious that this is the way cool apps should works : simple and fast ! :+)
Just for help : I can't extract the archive of WebGrabber you can find here :
http://www.epicware.com/webgrabber.html
It's a normal tar.gz file, and BomArchiveHelper extracted it without problem (as Stuffit).
hth

>>153

Confirmed, I'll add it to the list.

Thanks for this great app! More and more great pieces of software come out for the Mac these days. Very cool. Some of the last things I miss are a good Archiver that does RAR and a good mp3 tagger like mp3tag for windows.

sounds like a nice app, but since it's for 10.4 only, i can't try it. are there significant reasons keeping you from compiling a 10.3.x version?

>>157

Mostly that I don't have a 10.3 machine to test on.

The Unarchiver 1.1 crashes when opening this file:

http://www.pixelglow.com/downloads/graphviz-1.13-v16.zip

I also posted the crash log on pastebin:

http://pastebin.com/811153

>>123

The original 7-zip makes use of many win32 features, but I was talking about p7zip, which is supposed to be very portable.

>>160

p7zip is just exactly the same source code, but with a win32 compatibility layer compiled in alongside. It's a real mess, and compiling it into a separate application is nearly impossible.

The only really portable 7z code is the 7z-C code, which I am using, but which is less capable, as mentioned.

I'm curious about those random files that Unarchiver is unable to decompress properly. Are those because of obscure bugs in the decompression engine that only get triggered by certain files or are they because of bad compressors?

>>162

So far I've encountered one bad compressor, a couple of obscure bugs, and then there are a couple of still outstanding mysteries like the SIT files on Intel. That's PROBABLY another obscure bug, but I don't know yet.

once you get that SIT problem for Intel users sorted, and perhaps the contextual menu, I will gladly donate to you, and i'm sure others will too :)

great app. it's a favourite of mine, along with quicksilver.

The lack of a contextual menu like way to "Extract to..." is the only thing keeping me from donating som of my coins

Good news and bad news: Good news is I finally got an Intel Mac, and I am working my way through a number of Intel-only bugs (and others) now.

Bad news is, I managed to mess up my home directory drive in the move to the new machine, and I lost a whole lot of files. The Unarchiver isn't affected, since I could just download the 1.1 source again and start over with the few bug fixes I'd done so far, but I lost a lot of work on Xee, so that will be even more delayed.

This ZIP file that have a tracking application is not extracted correctly so it does not work when extracted with your aplication.

http://www.peerlessproductions.com/tuts/pages/Icarus.html

Hope this data help you in some way.

Can you reproduce the bug I reported?

>>159

BOMArchiveHelper also have trouble opening this archive.

Instead of implementing the various Finder Contextual Menu feature requests, maybe the developer can consider adding an Applescript dictionary along with a set of Automator Actions and Workflows in a later release.

There are several advantages to this approach:

1. It avoids adding bloat to the Finder menu, much like how windows applications love to add bloat to the explorer menu
2. It allows people to pick and choose which menu items they want
3. It is a lot more flexible. People can utilize TU in their custom scripts and workflows. They also have more options when it comes to accessing these functions: the finder contexual menu, the applescript menu, droplets, folder actions etc.
4. (Very important) It is easier to implement compared to a Finder plugin.

>>168

Oh yeah, I forgot to mention it, I could and I fixed it. Should work in the next version.

Oh, and >>169 is certainly worth thinking about, at least. Although I've found Automator a little annoyingly sluggish to launch on the old Mini, so I am not entirely sure.

Update on 1.2: All outstanding archive handling bugs have been fixed! At least all the ones I've managed to keep track of.

(This doesn't include stuff like SITX or RAR encryption though, sorry.)

This all sounds very promising and I'm looking forward to 1.2.

I'd also like to second the request for an AppleScript dictionary which would be preferable to Automator Actions.

What kind of commands should an AppleScript dictionary have, in this case?

Well I'd imagine that it should be things like having an Archive object which has properties such as:

• Source File
• Target Folder
• Delete After Extraction
• Open Target Folder After Extraction

I wouldn't expect anything too fancy but it would just be nice to be able to handle file extractions via AppleScript.

I use it to extract sit file.. but only find an empty extracted directory. why?

Well, I wouldn't rely on The Unarchiver extracting sit archives correctly. The problem is not with The Unarchiver, but with underlying library it uses, libxad. This library has got some obvious issues with sit archives.

I tried to use libxad for my own purposes. The sit archives I've used to test the library were made with StuffIt Deluxe 10. In many cases, libxad didn't recognised names of the files inside an archive correctly. As a matter of fact, the names were correct, but not full paths. That way, some files and folders ended up in completely wrong places in archive hierarchy, often not even in the same hierarchy level. I could recognise that since I knew what archive I created, but the user trying to extract sit archive with unknown contents is very likely to get messed-up hierarchy of extracted files. In case of app bundles, plug-ins and alikes, this would make them useless.

Another example is archive made with StuffIt Deluxe, all files recognised properly by the libxad library. But then, adding a new file in the root of archive (using StuffIt) results in the library being able to see only that new file, all others (couple of hundreds of files become inaccessible! Deleting newly added file brought everything back to normal concerning library's ability to correctly see all files.

Problems also exist with sit archives containing encrypted files. If only one file inside an archive is encrypted, the library most certainly won't see all files inside. And an attempt to extract those encrypted that are accessible results in library function ending with data corruption error.

So, as a conclusion: I don't know for other archive types, but as for sit, the libxad library, and that also means The Unarchiver, is (unfortunately) not reliable at all. If anyone still needs sit support, I'm afraid there's no escape from StuffIt Expander yet.

>>177

I have fixed quite a number of bugs in libxad's SIT handling, and 1.2 extracts all my test cases correctly. Well, except the encryption, I haven't done anything about that.

Cool, have you submitted those fixes back to the libxad project?

Some of them, but the project seems to be kind of dead and they haven't been incorporated.

Finally, v1.2 is done and released!

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

New stuff:

• Added several localizations: Japanese, German, French and Spanish. Many thanks to E-WA, Christoph Schmitz, Thomas Steffen, Thomas Didrel, and Oscar A. Mata T. for their work on this!
• Added an option to have The Unarchiver ask for a destination folder. Holding the command key while double-clicking an archive will also make The Unarchiver ask for a destination folder.
• Fixed many unarchiving bugs. Several problems with Zip files fixed, and SIT files should now work much better, especially on Intel machines.
• Fixed some other bugs in the interface, such as some problems with the filetype association list.

As you can see, I did not add some of the requested features like AppleScript support or a context menu item. I looked at both, and finally came to the conclusion that they were both enough work that I would never get this released if I started on them. There is a little workaround for the context menu though, as you can now command-click an archive and The Unarchiver will let you select the destination.

I still like the ideas, though, and I might add them in a later version. Even better would be if somebody wrote it for me and gave me the code, hint hint.

Lovely, thanks for the new release. I'll try it this evening (I have to endure a day of Windows at work) and hopefully it will fix all of my SIT problems. As for the AppleScript support, I certainly wasn't expecting it in the 1.2 release so, from my point of view at least, please mark it down as a 'very nice to have' for a future release at some point. Bug fixes are much more important than what is, I imagine, a fairly niche request.

I have the strangest of defects, so weird I don't even know if it's un unarchiver. I have tried to download the latest two nightly builds of Cyberduck (http://update.cyberduck.ch/nightly/ - builds 2560 and 2574). Using BomArchiveHelper tells me that it can't write to whatever folder I try to unzip to (generally the desktop, as that's where I'm doing all of this). Using unarchiver it chokes when it gets to a classes.nib file, spinning the processors up to max without having anything happen.

Here's the magic - I kill the unarchiver process in activity monitor. I then copy the latest unarchiver app zip file on to my desktop, and unzip it (using unarchiver). Instead of just unzipping the file and giving me the unarchiver app to put in place, I get a folder called 'TheUnarchiver1.2' which contains the unarchiver app, and an apparently functioning copy of the cyberduck app I was trying to unzip :)

If you need more info let me know.

>>184

Ah, yes, that behaviour with the files appearing in later unarchivings is a consequence of The Unarchiver crashing or being killed. It's pretty weird, but I have not bothred to do anything about it, since the program is not SUPPOSED to crash in the first place (and also it DOES let you recover some files).

I can reproduce the unarchiving problem, though, so I will look into the cause of this. (I am guessing it's a broken gzip compressor that causes it, but I'll need to check.)

Update: Yes, the file is not a valid gzip file. I might try to add a work-around for this in a future version, but I think it might be hard to handle it in a useful way.

For now, I suggest you tell the author of the program to switch to a compression program that creates valid gzip files.

(If anybody needs the specifics of the problem, see RFC 1952, http://www.ietf.org/rfc/rfc1952.txt, section 2.3.1, the "ISIZE" and "CRC32" fields are missing in the file.)

Hi,

Thanks a lot for a great utility. I would just like to make a small suggestion for an addition:

In the 'Info.plist' could you also add the 'CFBundleShortVersionString' so that the version number appears in the finder when the application is selected. It just makes it so much easier to know which version one already has.

Thanks

>>187

Added.

>>184

Update 2: There seems to be even more wrong with the file than just that, actually. There isn't much hope of extracting it correctly, but I did fix the bug that causes The Unarchiver to lock up on this kind of corrupted file.

Both of these fixes were small enough that I don't think it warrants a version bump, so I just silently updated the file. Re-download it to get the fixes!

>>180

Stink. If someone else (ie, BetterZip) wanted those fixes would they need to contact you about it?

>>189

They're all in the The Unarchiver source zip in http://wakaba.c3.cx/releases/mac/. It also contains my XADMaster.framework, which abstracts out a lot of the bother of dealing with libxad and presents a nice, Objective-C interface to use instead.

I've started getting errors while trying to build .pkg installers using Iceberg. The builds fail at the pax file portion of the build. The only thing I can think of that might be related is that I've updated to TheUnarchiver 1.2.

The system.log file reports entries like this...
Nov 16 09:54:41 MyMac /bin/pax: open on /tmp/pax.md.KY1o: Cannot allocate memory
Nov 16 09:54:41 MyMac /bin/pax: close on {5: Bad file descriptor
Nov 16 09:54:41 MyMac /bin/pax: error closing files: Bad file descriptor

Is there any possibility that TheUnarchiver is the cause of the problem?

c w a l d r i p a t m a c d o t c o m

>>191

The Unarchiver has no support for pax files (something I'd like to add if I could find the time, though), and looking at that log, it seems to be running the right programs and not anything related to The Unarchiver, so I doubt it. Unless it's something that happens earlier, but I can't think of what that would be.

I am running Unarchiver 1.2 on an Intel Mac running Tiger 10.4.8. Love the app, it is fantastic. However, I have one slight annoyance and I am not sure whether it is actually a bug in the program or something wrong with my Tiger OS.

Every once in a while (this seems to happen at random after restarts/shut downs), all the associations in the preferences for Unarchiver are unselected. I am pretty sure that it is not a Unarchiver bug, because at the same time this problem happens, Firefox ceases to be the default browser and I have to select it as default again.

Sorry for my double post.

>>196

I am not sure what you mean here. You only get the preferences window if you click the icon directly, and the only reason to do this is to change the preferences. When unpacking archives, there's no need to click the program icon.

I just have a tiny request here:

Can you remove the option to associate .jar files with The Unarchiver? While .jar files are zip files, they are meant to be executed rather than decompressed and associating them with an decompression utility would make it difficult for users to run some Java programs. Unfortunately, most novice users aren't aware of this and they just blindly click on the "Select All" button.

>>198

Are they, nowadays? When I last did some Java programming, on Windows a few years back, there was no way to run a jar file direcetly, as I recall. It had to be done from the command line, or through a wrapper. Most Java apps I've seen use some kind of other of wrapper, too.

Is there now some way to run jars directly?

>>199 see things like http://sourceforge.net/projects/wiki-flcelloguy, which runs for me (On Windows, natch) with just a double click.

also, 200GET