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:
For actual information on the current state of this project, read on!
Sounds like there's a filetype conflict with some other app, then. The Universal Type system in OS X is a bit buggy that way.
it doesn't support .sitx archives. if it was added,i will delete stuffit。
I love the idea of The Unarchiver. Unfortunately, after installing it, I still had to install Stuffit because The Unarchiver, being able to decompress .sit files, couldn't do with just one. The Blank Dock Separator package available at MaxThemes. I am now on a brand new machine without Stuffit and would like to keep it that way, but have unfortunately forgotten to back up the separators, yet again. Does anyone have them and can repackage them in say .zip for me? Thanks! Kudos to the developers though for a killer app!
That file unpacks just fine for me. Were you using an older version earlier? There have been a lot of bugfixes to StuffIt unpacking in the later versions.
A small update for The Unarchiver:
http://wakaba.c3.cx/releases/mac/TheUnarchiver1.5.zip
This should, I hope, fix the problem with Xee where archives would fail to open. It also adds a Traditional Chinese localization. Other than that, nothing much has changed.
The .pax support is working great! Thx!
But, if I try unarchive an password protected rar arhive, The Unarchiver popup the password window.
But if I type the CORRECT password (100% it's correct, becase I can unarchive that file with unrar from console with same password) The Unarchiver give me a message window:
"Could not extract the file 'the file name': Command is not supported"
Hi! I found a spelling mistake in the german translation! A pop-up windows says:
Der Inhalt der Datei ... konnte nicht mit diesem Programm entackt werden.
Right:
entpackt (the "p" is missing)
Hi again!
I tested to open a passwort protectet .rar file (I made by myself with SimplyRAR)
but there's no passwort pop-up - instead a pop-up that says:
The contents of the file ... can not be extractet with this program.
RAR password support is not yet implemented. I'm hoping to have it in 2.0, whenever I find the time to work on that.
Thanks, fixed.
0.5 works fine so far in 10.3.9 so far (1.5GHz 15" PowerBook with 2GB of RAM); I used it for expanding a .tar.bz2. It doesn't have a Dock icon though, but I'm not sure if that's intentional or not.
Thank you very much for adding 10.3.9 support. I had all but written it of for when I get Leopard.
I downloaded phpMyAdmin in .7z format but The Unarchiver gave errors about unknown data formats when trying to extract it. 7zX handled it fine.
http://prdownloads.sourceforge.net/phpmyadmin/phpMyAdmin-2.10.0-rc1-english.7z?download
The Unarchiver uses the 7zC code from 7-zip, which doesn't support all formats (which is nearly impossible anyway, as 7-zip is defined as supporting a ridiculous amount of formats for no good reason). I've tried to nag the author to update it, but I don't think he has yet.
Hi,
Just a little request, why don't you add growl support > http://growl.info/
Sorry if this has already been asked.
Thank you for this app :)
I'm not sure it's very useful, as an unarching operation doesn't take more than a few seconds in the average case.
There appears to be a bug, introduced between 1.3 and 1.5, with password handling for encrypted ZIP archives. In 1.3, you can type the password, click Continue, and all files in the archive are extracted successfully. However, in 1.5, roughly half of the files fail to extract. (This is on 10.4.7, by the way.)
I need a test case to fix it.
Problem ... The Unarchiver simply closes right away if it has no write access to the folder of the clicked RAR file. It would be a good idea to either throw up an error message saying no permission, or ask if the users wants to extract somewhere else instead.
I'll add that to the list.
Is there a way to get StuffIt to stop stealing The Unarchiver's application default preferences? I even tried the Default Apps preference pane add on and StuffIt just won't stop being a jerk.
Are you using Firefox or Camino, and getting Zip files associated with StuffIt when downloading? This is caused by a Mozilla bug that they refuse to fix. You can work around it by choosing "Get Info" for one of the affected files, changing it to The Unarchiver, and then clicking "Change All".
Re: 256
I can't give you a test case file (too large, for one thing.) However, here is the problem:
--- /tmp/TheUnarchiver1.3_src/libxad/portable/mac/XADArchive.m 2006-11-24 09:22:52.000000000 -0800
+++ /tmp/TheUnarchiver1.5_src/libxad/portable/mac/XADArchive.m 2007-02-08 17:40:46.000000000 -0800
@@ -1053,7 +1069,8 @@
else if(detected_encoding) encoding=detected_encoding;
else encoding=NSWindowsCP1252StringEncoding;
return [password cStringUsingEncoding:encoding];
return [[password dataUsingEncoding:encoding] bytes];
+// return [password cStringUsingEncoding:encoding];
}
Clients of _encodedPassword (i.e. xadFileUnArc) require that the password be maintained as a null-terminated C string. (This means you can't use any encodings which might have embedded nulls as part of the encoding.) Also, dataUsingEncoding won't null-terminate the data. If a null char happens to immediately follow the data then the password works, but if not then the string continues until a null is reached, and so the password is (often) wrong.
Going back to cStringUsingEncoding for the password works just fine, since it appears xadFileUnArc can't handle anything else.
Thanks for tracking that down, but the problem is that cStringUsingEncoding is 10.4 only, and thus I can't use that. I'll have to look at other options.
In that case, this should work (haven't tried compiling yet though!):
char nullChar = '\0';
NSMutableData *pwdData = [NSMutableData dataWithData:[password dataUsingEncoding:encoding]];
[pwdData appendBytes:&nullChar length:sizeof(char)];
return [pwdData bytes];
There will still be problems if the password string's encoding contains any nulls (like Unicode), but I don't think that's going to be a common case, and xadFileUnArc can't handle such encodings anyway.
Actually, you can just use increaseLengthBy:, as the new data will be initialized to 0. I'll probably go with that.
The Unarchiver hangs when you cancel the extraction of a rar file. Shows "Preparing to extract ..." message as though it is working to extract the file although it was canceled before selecting a destination. I'm running 10.4.8, 1.83 Core Duo with 2GB Ram
Known bug, will be fixed.
TheUnarchiver used to extract archives into a subfolder of the current folder named after the archive file... it doesn't do that for me any more, and I'd really like it to. Did I screw up a setting, or has that feature been removed? (or maybe I'm just hallucinating again...)
It does this if there is more than one file or folder in the archive. If there is only one, it is not put in a subfolder.
Ohhhh, that makes sense, I guess. Still, it would be nice if there were an option to always extra to a subfolder, since if you don't know the name of the file inside the archive, it could be an issue finding it in the finder window, since it always alphabetizes on the fly. Making a subfolder with the same name as the archive will make the subfolder show up right next to the archive in Finder, which would be great!
It's been requested before, so it'll probably show up sooner or later. Maybe not in the next version, but I'll add it at some point.
Hi,
Absolutely bizarre problem with the unarchiver in regards .sit files.
Mac OS does recognize it as an application that can open .sit fles (all other archive types yes, but not.sit)
It can happily open .sit files, but assigning it as the default application seems impossible.
Any ideas?
Well, let's just say that Launch Services, which handles this stuff, is... less than well-designed.
Something similar has happened to me when I had another program installed that defined a UTI with another name for the same extension. You'd have to use something like RCDefaultApp to see if that is the case, or to delete suspicious apps (AND empty the trash, or else it does not count).
If you can find an app that causes it, send me its Info.plist!
Hi, been using The Unarchiver on 10.4.7 (PPC) and again on >=10.4.8 (Intel) with absolutely no errors so far. Thanks for a fantastic app!
Is there any way to automatically associate all supported compression types with The Unarchiver? In the past I just used "Change All" in the Info window as I came along files that opened with BOMArchiveHelper, but having an easy way to set all of them at once would be very convenient.
Also, any plan on making "The Archiver"? Would be nice to replace the "Create Archive" option in Finder's contextual menu with options to create compressed tars (tgz and tbz2 preferably) and such.
Doubleclick The Unarchiver, and you get a preferences window that has a list for associating filetypes.
Also, sorry, no plans for The Archiver. I am generally happy with what's available already, personally, and I've got lots of work as it is.
Another release of mostly bugfixes and tweaks:
As pointed out on MacUpdate, The Unarchiver defines for the system the filetype of "RAR-Archives" as files ending on .rar, .RAR, .r00, r01 etc., as well as .001, .002, .003 etc.
The problem is that multi-part split files also end on .001, .002 etc. The Unarchiver is unable to open/merge these files (which I would not expect it to do, anyway - it is an unpacker, not a filemerger).
I cannot dissociate .001-files from The Unarchiver without dissociating .rar-files as well, since both are defined for the system as rar-archives.
I would like to propose, that in the preferences a seperate filetype for .001-files ("Multi-Part Document"?) is added, which can be ticked or unticked to be opened by The Unarchiver. That way, the user can choose if he wishes to open .001-files with The Unarchiver or a different program.
I hope that is not too much to ask. I feel the program is amazing, and the developer has been doing a great job!
Also (since I seem to be the roll right now :-) ), I would just like to register my vote to keep the current behaviour of The Unarchiver of extracting one file archives into the current folder and archives with multiple files into a new subfolder.
It has been requested on MacUpdate that ALL extractions should be into a new folder, regardless if one or multiple files. I don't think that is a good idea, and at least should be optional for users who prefer the current way.
Once again, Launch Services is being a useless piece of crap... sigh. Oh well, I guess I'll have to go with making a separate file type for those, although I can just tell that will lead to some other problem instead somewhere down the line.
Yeah, I'd only ever make than an option, and it definitely wouldn't be the default.
Hmm, I can't extract .sitx. Not supported yet?
Thanks.
Sorry I just founded out with sitx. I hope they release some docs before too long.
It cannot open password protected files!
It cannot open password protected files!
Yes, it can. Just not all of them.
I get errors when trying to extract the zip for NuFile (which BOMArchiveHelper has no issues with) (In the .rtfd/):
http://growlichat.com/downloadredirect.php?id=33
Would it be possible to add the version number to the main window so I can quickly tell which version I have?
Right-click the app and Get Info. If that doesn't show anything, you have a pretty old version.
Although it appears that file does not open in the current version either. I'll add it to the list.
I haven't tested it recently but it won't extract a working version of Adobe Flex Builder (Beta).
When trying to run Flex, it does nothing. I attempted to extract with Bom and it worked.
I need the actual file or at least a link to it before I can do anything about it.
Yes, I realized it was available in the Get Info window (I have the current version), but thought it might be easy/good to list it in the main window, so I wouldn't have to try to find the application to run Get Info on it.
I just noticed after extracting a rather large zip file that the modified date of the folders were set to today if the folder had anything in it and to the original modified date if it was empty. I recognize that the file system is doing this as the folder contents are written. From the point of view that the extraction should result in as exact a copy of the original as possible, shouldn't the folder dates be reset after they have been filled?
How do we donate to you? It looks like a lot of people are loving your application and you're putting in some serious hours on it over the last few months. I'm hanging out for v2.0 and password protected rar support... can I paypal you a few bucks to help with a beverage of your choice while you work?
There is a donation link on http://wakaba.c3.cx/s/apps/unarchiver.html if you want to!
i love this little tool, but many password-files (for rar's) didnt work with the unarchiever :-( Please do not give up the development. The Speed is amazing!
Just plaudits: Thank you so much for this wonderful, well designed utility. Obviously, a lot of work and thought has gone into it. I can't imagine an unarchiver with a better interface or more complete (useful) functionality. So thank you!
Unless somebody is already doing it, I would be glad to translate The Unarchiver to Italian; all I need to know is which files I have to modify in order to complete the translation. Do I have to translate only the strings inside "Localizable.strings" or there is something else?
Thank you very much
My e-mail address is francesco (at) allascala (DOT) it
I found a case where using Unarchiver v1.6 on a rar file of an iso disk caused Unarchiver to run forevvvvver, using about 70-85% system resources. I eventually Quit the program from Activity Monitor.
I tried the same rar file in UnRAR v2.2, and it ran through the extraction, up to 99 %, looked like it would finish, but then its status window reported a CRC error. and finished the process. The reported error statement from UnRAR: "CRC failed ??? - the file header is corrupt"
So I am guessing that Unarchiver 1.6 got hung on the CRC error and never quit. But why use up all the system resources in that? And no feedback in the Unarchiver other than a perpetual 'spinning' bar.
And I think it would be good if Unarchiver would give some sort of status indicator, both of progress and outcome (or failure).
(I looked in Console logs, did not see anything that looked like unarchiver)
Thank you. All the best.
That was obviously not intended behaviour. I can't do anything to fix the bug without a file that causes it, though.
i had another 324mb 7z file today, and same result.... i can tell you where to download it from but would rather do it in a private manner... please let me know if you're interested... thanks :)
p.s.
i think it is not necessary though... just create a 300mb+ 7z file using any capable utility, and try extracting it with the unarchiver and you should see the problem...
No Sitx support :(
Goddamnit, I can't wait for the day when I can get rid of stupid Stuffit once and for all.
Would it be possible for the window that appears when you are unarchiving something to be like the BOMArchiveHelper window and float above everything but isn't actually "selected" so you're still in the Finder even though the window is floating above it?
I'm dying having to use unrarx to get at my password protected rar files (I interface with a bunch of Windows users who use encrypted rar every day!). Can you give us any idea at all on when we this might be ready for release? I am more than willing to help with testing...
I'm dying having to use unrarx to get at my password protected rar files (I interface with a bunch of Windows users who use encrypted rar every day!). Can you give us any idea at all on when we this might be ready for release? I am more than willing to help with testing...
Request: I'd like to have the preferences set to extract archives to the same folder but option+double clicking will give you a dialog and prompt you where to extract it (I'd mainly use archives on network drives so I don't have to transfer the file to my CPU and back again across the network).
Does this program support ace compressed files? Also multi-part ace. Retrogamers on Windows seem to like this method and I have yet to find a solution.
Sorry, no. The format is propiatery and only available under NDA, apparently. One of the main programmers of libxad, that I use to unpack lots of stuff, has gotten access to the source but hasn't gotten around to implementing it. I don't know if he ever will, and it's beyond my abilities, so, sorry, no time soon.
Is there a known bug concerning Unarchiver's inability to finish extracting an ISO file? I tried two separate files and it hangs on both of them right at the end.
Hi, using The Unarchiver 1.6 I encountered a problem when decompressing a file in a deep subdir from a tar.gz archive. I created a sample archive showing the same problem and uploaded it here: http://www.maxloresti.com/testdir.test01.tar.gz
It only contains a dir and a bunch of subdirs, which in the end contain only one small file called "definition.xml". When I extract the archive using The Unarchiver, the name of the extracted file is "definition.xml0000644". The appended numbers really look like permission bits... :)
StuffIt Expander correctly extracts the file and the whole archive.
Hi,
First off, Unarchiver is a great program. It works so well.
Does anyone know if there are plans to add the ability to open password-protected zip files in a future release? Thanks.
You can already open some password-protected zip files. If you have one that can't be opened, I'd like to see it or else I can not add support for it.
I just found what will make alot people happy about the password glitch that appears to fault some RAR files.
http://www.unrarx.com/faq.html
Download this program and follow the instructions. It's not as sleek as Unarchiver but.... IT DOES the Job when it comes to Passwords on RAR files even split ones. I just thought I'd share this with someone who may have been going up a wall with password files.
Let me know if it works.
"Icons for .sit files aren't showing up for me (in fact it's been hard enough getting .sit files to open with The Unarchiver at all - it doesn't show up under the Open With menu)."
I'm also getting the same problem as gannet. Anyone else?
"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."
Nick's fix doesn't work for me.
You probably have some other program installed that conflicts with The Unarchiver's filetypes. Launch Services is pretty broken when it comes to these things.
Are the duplicate extensions in all caps for supported file types really needed?
I don't really know, but Preview.app has them.
Thank you GaryGnu! UnRarX worked for the password protected rar files at:
http://radiowaves66.blogspot.com/
The Unarchiver kept on giving me errors that the "Command Is Not Supported".
Two questions.
1) Which SIT formats are supported? 1.5? 2.0-4.0? 5.0?
2) Does it support .zip archives whose contents have MacBinary metadata as implemented by Tom Brown's ZipIt?
You need to make the program follow the language rules. So if i chose not to install any languages except english and french and I installed the OS, when Unarchiver installs it should only install English and French as languages and not installed any other one. If a user wanted to add another lang. they can download it drom the site and add it through the "Get info" screen. This feature should be added cause it makes the program smaller for the end user.
The app needs to follow OSXs language rules. If i dont install russian with the OS russian should not be installed with the app
Somehow I think most users can afford the extra 400k.
Ha, I've discovered the problem with .sit files! The Unarchiver is simply missing a UTI: com.stuffit.archive.sit
I added this to the info.plist and it works fine now :-)
I have AppleScript code for determining if a file is Stuffit 1.5, 2.0-4.0, or 5.0; it's called StuffTyper. Hmm, looks like I never uploaded it to my website; I can send it to you if you'd like to see the code (it's just a kind of magic number checker). You will then have a way of determining which .sit types people sent you. (It's not a catalogger, but you could modify the script or use it in conjunction with something else, like File Buddy.) If you want me to send it to you, just tell me how you'd like it sent.
Um, I don't quite see the point. The Unarchiver can handle any .sit file already.
Speaking of types though, I believe 'SIT!' is a creator type, not a file type. 'SIT2' perhaps?
I used The Unarchiver on a Windows exe-file and it run forever, I quit the program with Activity Monitor, because there was no response. Now I have lost 10GB of my Diskspace. Is there tmp, I can delete?
There's probably a hidden folder in the same folder as the file you tried to unpack, which starts with a ".". You should be able to see it from Terminal.app, at least.
yes, SIT! is a creator type for StuffIt Deluxe (Expander is SITx). SIT! is also the file type for StuffIt 1.5 files. StuffIt 2.0-4.0 uses 'SITD' filetype and Stuffit 5.0 filetype is 'SIT5'.
My script checks the internals and sets the filetype metadata accordingly.
Hi there,
same problem as post #320. I always get the errormessage:
"Command Is Not Supported" on archives of page
http://www.doloresoriordan.net/eng/video.htm
even if I specify the correct passwrod. The archives are fine, unpacked them using UnRarX, but your tool is looking much better, so I would like to use your tool.
Password-protected RAR is not supported yet.
Please add an option to use the archive's name for a destination folder. I have a lot of archives with good archive names, but unintelligible or abbreviated folder names inside the archive. When I extract them (especially if processing several at a time), I have no idea what folder matches to what archive.
Already added, but I forget if it's in the release version or just my development version.
>>333
Hm okay, it's just Expander includes recognition of 'SIT2' but not 'SIT!'. Are you sure SITD isn't StuffIt 3.x-4.x with SIT2 being StuffIt 2.x?
Anyway, has that StuffIt UTI I mentioned been added to The Unarchiver?
Would you add a command line interface? I am downloading compressed files, manually processing them with The Unarchiver, then parsing them into a database. I would love to be able you use your tool to automate the process. I would love it even more if it were available in Ruby!
It's something I've thought would be nice to have, but I haven't actually needed it enough to make it.
If you're feeling like doing some programming yourself, most of the magic is in a framework, which should be pretty easy to use. There's even a very simplistic command-line tool already for testing purposes which might be expanded. Or maybe you can bridge the framework into Ruby somehow.
If you do any of that, do let me know.