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!
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'!
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.
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.
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
Once again, without the files, I can't do a thing about it.
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
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
If you can supply an archive that uses this, I will certainly look into adding support for that.
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!
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
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
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?
Without the actual files there is nothing I can do about it.
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.
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.
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.
> 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...
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)
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
Love it, works perfectly. Thank you!
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
the numbering goes
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!)
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 */
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.
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.
At what point do you get an error? The installer started up fine for me, but I did not try going through with the installation.
Error was right at the start. I see what the problem is now though.
I have "Create a new folder" is set to always. The new folder created appears to be the package (and will launch the installer since packages are folders named *.pkg), but it actually contains the correct package (if that makes sense?).
Perhaps something to check and adjust the names of new folders created in these cases.
Ah, I see. Not sure how exactly to fix that, but yes, something should be done about it.
I like the move archive to trash function and use it most of the time.
Sometimes however I need to open an archive without trashing it (a seeding torrent for example).
It would be nice if there was a way of disabling this on a temporary basis with a modifier key (like the extract to folder)
It would also be nice if the modifiers could be configured in the preferences.
Also, if I bring another window in front of TheUnarchiver during extraction from the finder, there appears to be no easy way of bringing it back to the front without hiding everything else, as there is no application in the dock and it does not appear in the finder window list.
"Sometimes however I need to open an archive without trashing it (a seeding torrent for example).
It would be nice if there was a way of disabling this on a temporary basis with a modifier key (like the extract to folder)" and an option to float the window so it can't be sent to the background.
2. another note, can anyone try decrunch
http://www.twinbirds.com/goattracker/GoatTracker.zip ?
it returns errors on any drive except a fat32 drive i have. if the file is in the fat32 it decrunches well with the unarchiver.
could it be a bug related to a hfs volume?
3. i suggested before but here goes again, hjsplit joiner would be too hard to implement? what about auto-extraction for dmg files like in special move (which i think is a hidden os feature): http://www.fruitz-of-dojo.de/php/download.php4?dlnr=9
thanks and cheers, !WAHa.06x36.
I can confirm that that file doesn't extract here either, I'll look into it.
There's an issue for simple split files here: http://code.google.com/p/theunarchiver/issues/detail?id=221. Does HJSplit just cleanly split files, or does it add any extra wrapping, do you know?
Also, to do DMG properly in The Unarchiver, I'd have to actually implement a full HFS+ reader. It would be nice to have, but is too much work.
thanks for the reply.
about hjsplit, from this page (portuguese)
http://blog.mcsx.net/hjsplit-juntando-arquivos-separados-sem-hj-join/
it says that hjsplits splits files but doesn't use an actual file format, just splits bytes directly in raw mode without any means of cyclic redundancy check to know if the file is intact or was modified (bit flip) when downloading or got corrupted in the hard disk.
what it means i don't know. :\
machacha is opensource and handles hjsplit, maybe you can get the code.
homepage: http://homepage.mac.com/julifos/soft/machacha/index.html
pdf about file formats including hjsplit (from machacha homepage): http://homepage.mac.com/julifos/soft/machacha/specs.pdf
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 window again to enter the password.
This turns out to be really annoying, but I think I've got it covered now.
All right, let's call this a release:
http://theunarchiver.googlecode.com/files/TheUnarchiver2.3.zip
>>711
WuWi
tested over 100 DiskDoubler files that did NOT previously expand with The Unarchiver
--and--
it works!
Thank you.
I also found a copy of DiskDoubler 3.0.1
Would it be useful to you?
I haven't thought about it much yet. I guess one solution that isn't very good but would work is to just make it possible to manually choose the encoding when entering a password. This would also help for files where the encoding is guessed wrong.
But that requires updates to the UI resources and translations, so I'll wait until I have some other changes to apply too, it's a bit of a bother to get everyone coordinated to do an UI update.
Good to hear!
Can you check if you can make a file with 3.0.1 that will not open in The Unarchiver? If you can, that would be very useful. Try different compression methods and see if one of them doesn't work.
Oki Doki.
Take your time.
It's not important things. : )
>>715
Method A will expand with The Unarchiver
Method B will NOT expand with The Unarchiver
What would you like? Method B file and/or DD301
Both expand with DD301 and DD410
I guess the best would be both! I have an emulator somewhere that might run it but that's a pain to get running.
>>718
ok... I am sending dd301.zip
It has dd301, good Method A and trouble maker Method B
thanks for split file support.
it sucks when i have to keep 2 or 3 apps to do one thing.
Ah yes, method B is indeed method number 2, which is the one I still lack. (Method 5, too, but it's apparently the same as 2 just with another parameter.)
When I have some time to play with reverse engineering again I'll have a look at it. Thanks!
if i hit return after entering the password for an archive (instead of clicking ok) the whole program seems to freeze up. if i open another archive it will show up in the window but i can't do anything with it. if i double click the icon i get no preferences. a blank unarchiver window will just stay in the background and can't be force quit (or regular quit). it happens every time. this is a TERRIBLE bug and if it's been reported i apologize, for i don't have time to read through this thread, but it keeps me from using unarchiver as hitting return after typing is something ingrained in my mind.
Some people have reported similar problems, but I can not reproduce them, and thus can't figure out what is going wrong.
Do you have any haxies or anything similar installed? Do you have a second machine you can test to see if it has the same problem?
>>721
Any idea which version of dd had Method 5?
Nope, not really. Well, 3.0 seems to use 1 and 2, and 4.0 uses 6, 9 and 10, so maybe something in between? Although I noticed some of the other related programs might use other methods. And method 8 seems to be older than many of the others too (and is the same as in Compact Pro), so it's a bit of a mess.
I wanted to alert you to an issue that I ran into with Unarchiver. I tried to download a wireless broadband configuration application (you can get a copy of it here: http://www.clear.com/support/download -- d/l the Mac version 1.03.1031.0).
The problem was that the installation of that application failed. I was on the phone with that company's tech team multiple times and still could not get it to install properly (see attached image).
Then I happened to download it via Safari (which automatically opens zip file with the standard Mac OS X archive utility). Amazingly the installation worked that time.
The problem was related to the fact that I was always unzipping the file using The Unarchiver. And for some reason, TU was corrupting the .app file in the zip.
I thought I would let you know and let you take a look at the zip file in question.
I love TU, but in this one case it really messed me up for days.
Which version were you using? Try 2.3 if you haven't.
Regarding Issue 727 reported by "archecht"
Curiously ! I have done some tests myself (on OSX 10.6.2) and I have observed that if extracted with –
both, Uninstall Script and Install Package, fail to work !
Uninstall Script works but Install Package fails to install !
both, Uninstall Script and Install Package, work !
both, Uninstall Script and Install Package, work !
with the observation that Apple Archive Utility produces an Install Package with different size, if compared with those produced by the rest of the above utilities.
4 tools = 4 different results !?
Very mysterious. At what point exactly does the installer fail if extracted with The Unarchiver? I tried unpacking it, and it started fine but I didn't want to install any unknown software so I didn't go through with it.
Also, did you spot any obvious difference between the extracted contents of the installer?
>>730
my apologies ! because is no big problem
just that permissions were not set correctly by default when extracted with The Unarchiver and Springy !
sorry again ! I was rushed !
pigz is a reimplementation of gzip for multiple procs. Can you pretty please replace the gzip code with pigz?
Answers to some of the questions 728-733...
>>728 I tried version 2.3 of TU, and it stills has this problem (install fails).
>>730 The install fails right at the start of installing any files, so you won't really be installing anything.
TU produces an installer that fails and is 6,939,287 bytes, and Apple Archive Utility produces one that works and is 6,894,913 bytes. Not sure without looking closely what the difference are.
>>735
Hello 'achecht', have you read post 731 ?!
There is no big error ! You just need to fix permissions for all enclosed folders and files ! You can use for this a graphical tool such as 'BatChmod'
Regarding size difference between TU and AU, I do not know why this difference, but both packages works !
First off, many thinks for enabling me to say NO to Stuffit. Second off, I saw some folks had been asking how to compile. I got it to compile on Snow Leopard (10.6.2) with XCode 3.2.1. I initially ran into problems with #include_next
's, but found that by unsetting some of the user settings I could get it to compile. I'm a command line kinda guy, so here's the commands I used to build and install the app in /Applications after downloading TheUnarchiver2.3_src.zip
:
unzip TheUnarchiver2.3_src.zip
cd The\ Unarchiver/The\ Unarchiver
xcodebuild \
SDKROOT_i386= SDKROOT_ppc= SDKROOT_x86_64= \
MACOSX_DEPLOYMENT_TARGET_i386= MACOSX_DEPLOYMENT_TARGET_ppc= MACOSX_DEPLOYMENT_TARGET_x86_64= \
GCC_VERSION_i386= GCC_VERSION_ppc= \
HOME= DSTROOT=/ install
cd ../..
rm -fr The\ Unarchiver
I have a strange problem with The Unarchiver. When I download an .rar file, The UnArchiver automatically tries to unarchive it as soon as the file has completed downloading. I have found no way to shut this off. It is really annoying when downloading a multi *.rar set of files, because it will try to unarchive each part.
I'm using the latest Snow Leopard. Is it possible I have something set in the OS that is doing this to me?
Thanks!
This is a very useful program, thank you.