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!

>>848

Apparently there's already a library written in C that has similar functionality as The Unarchiver.
http://code.google.com/p/libarchive/

RAR support is still not implemented though.
http://code.google.com/p/libarchive/issues/detail?id=40

Would you mind if I ported the relevant RAR code from The Unarchiver for use in libarchive? If so, would you mind if I relicensed the ported code under BSD? libarchive is under BSD license.

>>851

Any code that I wrote from scratch I'm happy to re-license under BSD. That would include the RAR code, but I have to warn you: It might be a lot more work than you think. RAR is a real mess of a file format, and the implementation in The Unarchiver may not be easy to follow, no matter how hard I've tried to make it such. However, having a portable and open implementation of RAR would be a very good thing, so I think it is worth a shot.

(Also, it has at least one known bug that I need to get around to fixing.)

>>852

Thanks :)

The Unarchiver fails to extract all files from a .rar archive (see attached file), yet Zipeg is able to successfully extract all files. FYI.

>>854

Seems to work for me, but I already fixed some RAR bugs so that's probably why. Try it with 2.6 when it gets released (should be pretty soon).

Well, 2.6 is done. This one focuses on adding support for more old formats, and bugfixes.

• Added support for Now Compress and LBR.
• Improved DiskDoubler support. Almost all modes are now supported, including hardware-accelerated ones.
• Better support for ARC, including proprietary PAK algorithms.
• Better support for Squeeze and Zoo.
• Several bugfixes for RAR, Zip and Compress files.
• Fixed broken handling of multi-part files in unar.exe on Windows.

unar and lsar have also been updated to 0.3, with the same changes. Otherwise they remain as before.

Is there any way to extract files and overwrite files of the same name rather than appending '-1' to them?

Ever thought of making a Cocoa framework and releasing it under a BSD license? It'd be a huge benefit to the Mac developer community!

>>858

http://code.google.com/p/theunarchiver/source/browse/#hg/XADMaster

Speaking of frameworks, I was just scratching my head wondering why The Unarchiver breaks my symbolic links, but doesn't break frameworks in app bundles (which contain symbolic links). Turns out it only breaks absolute symlinks.

I'd submit a bug report if the "Bug tracker" link worked, but it craps out (http://code.google.com/p/theunarchiver/).

To clarify, try this at home:

• create a folder named fonk, inside of which you put 3 files:
• a file named zonk.txt
• a symbolic link to zonk.txt with absolute path (path-to-fonk/zonk.txt)
• a symbolic link to zonk.txt with relative path (../fonk/zonk.txt)
• zip fonk (I used the Finder in Mac OS X 10.6.5)
• extract it using BOMArchiverHelper.app: both links still work (the absolute one points to the original, the relative one points to wherever you extracted it as long as the folder name stays fonk)
• extract it using The Unarchiver 2.6: the relative link works, the absolute one doesn't

Could I make two suggestions that I'd love to see?
One is a way to tell which version I have installed, and the other is creating some kind of profiles in the extraction tab. I ALMOST ALWAYS want to purge the archive, but sometimes don't, and configured the app to send to trash. But when I don't, I have to go to trash, Put Back doesn't show up, and I have to manually drag to the original location,,, If I could configure the default actions, AND the actions with a modifier, it would be great... eg. Just double click sends to trash, holding COMMAND the archive remains, holding OPTION send content to Desktop and purge archive, etc.
Thanks, I've donated, awesome app.

The rar file from http://legroom.net/scripts/download.php?file=uniextract161_noinst doesn't work in the Unarchiver but does with the command line unrar. I believe this is a bug with the Unarchiver.

Hi Everyone,

I get ZIP files that are created with Winzip on a German version of Windows Vista.

The Unarchiver 2.6 thinks the encoding is Windows Latin 1, and garbles the ä in the name of the zipped document. I have to change the encoding to Dos Latin 1 in order to have the document name extracted correctly

Can this be fixed?

Thanks,

Hans

>>865

Does the Mac builtin tool ( BOMArchiveHelper ) unzip correctly?

To test, disable Unarchiver for zip files, ie un-check "Zip Archive".

>>864

I can't reproduce this. What version are you using?

>>865

Probably not. Guessing encodings is not an exact science. If there are not many special characters to work with, it's mostly impossible to get it right.

I had problems unarchiving a vast collection of 114 sequential .zips (the final .app is +11GB...) so I resurrected The Unarchiver from the Trash to see if it might help. It didn't but it reminded me why I had trashed it in the first place: it is unable to handle such large files. It has been running for thelast 2+ hours, saying 'Preparing to extract <filename>'. A search for a part of <filename> via Easy Search' - set to find all files and folders, to ignore case and to search invisible etc. locations - finds nothing new to indicate that it is even writing anything to a file anywhere. Stuffit Expander took a fair while (many minutes) but completed, if not successfully.

Any suggestions why it should not go back into Trash?

>>868

Did you try the latest version?

Without the files in question there is not much I can do to fix it.

yeah -- opensource un- .sit -ter for Windows.
Did I miss some instructions?

Problem though: when I run
c:\> unar.exe test.sit
I get "This application has failed to start because Foundation.1.0.dll was not found. ..."

*** Where can I get Foundation.1.0.dll ?

>>870

Maybe I forgot to package it? Try to download one of the older versions and see if it is included: http://code.google.com/p/theunarchiver/downloads/list?can=1&q=unar&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

Hey guys,

I keep getting the following error message:

The contents of the file can not be extracted with this program.

It is a .zip file, which was created through the joining of multiple .z01, .z02 files etc., joined together with Machacha program. Can anyone advise?

Thanks

>>872
i'm pretty sure multi-part zip files don't work like that.

When will 7z encrypted archive support be added? That's the only thing that forces me to use Stuffit :( All of the 7z archives that I come across are encrypted :((((

Please add The Unarchiver to the new Mac App Store ASAP!

>>875

If somebody feels like paying for a developer account, then I'd be happy to do so.

I hate stuffit!!!
Please upload the unarchiver to the Mac App Store yes!!!

The Unarchiver is almost perfect (for me)! There's this one thing that I'd LOVE to see it do: Add 'Never' as an option under Extraction Preferences, 'Create a new folder for the extracted files:' This would give me the exact functionality I had when using UnZip and UnRAR under Windows for multisection zip files.

Also, can I control the functionality from the Terminal prompt? Thanks!

>>878

A "Never" option would force it to have to deal with file collisions, which would a lot of required functionality I'd rather not spend time making.

Also, there are the lsar and unar command-line utilities, but they are still somewhat beta.

>>878

A "Never" option would force it to have to deal with file collisions, which would a lot of required functionality I'd rather not spend time making.

Also, there are the lsar and unar command-line utilities, but they are still somewhat beta.

First of all, Thanks for supporting a good program.
I have qustion for you.

We're trying to develop a program about auto extractor
on MacOsx 10.4 Tiger ppc.
But UnArchiver is not compiling on 10.4.
I guess, It includes framework that is devloped on more than
10.4.

If it is possible to compile, please could you tell me to
compile.

==============================================================

>>882

It may be that it needs newer SDKs, I have not had a 10.4 machine in some time so I haven't been able to try building it on that. You are pretty much on your own there.

In the worst case, you can just use the already compiled version of the framework from The Unarchiver.app.

>!WAHa.06x36

I'd really like to see The Unarchiver in the Mac App Store.

Why don't you put in big red letters on top of the Xee and The Unarchiver page that you're seeking donations for Developer membership so you can put Xee and TU into MAS? I think people would be a lot more inclined to donate if there was a clear description as to why you're seeking donation and the amount of money raised for it so far.

What do you think?

I have found a bug I can reproduce.
If a rar file is password protected - I have to insert the password and confirm it by using the mouse. Otherwise (pressing enter) will result in a hangup.

MacOS 10.6.6

>>885

That is weird, I think I always just press enter when testing. It definitely doesn't break here.

Do you have another machine you can test on, to see if it does the same thing?

Hello. Great app you've got here. I'm having an issue some others are having too. So far it only happens if I enter the wrong password. The window goes blank and there's no X button. When I try 'force quit,' Unarchiver doesn't show up, so the only solution is restarting my Mac. This is with 2.6, on a PPC G5.

For those who encounter, "can't expand this file," I used to have that problem with .rar files, but then I discovered that some of the files didn't download complete. Once I got them again complete, Unarchiver worked fine.

It would be nice if The Unrachiver used Growl.

Is The Unarchiver going to be available through the AppStore?

I'm bored so am going to test it on Debian 5.0 "Lenny" - I can provide binaries if you want too.

OK, I built unar/lsar on Debian, and lsar works fine. unar, however, throws a Segmentation Fault on run.

I'm curious no know why this project is unable to open encrypted 7z files. It is one of the only "popular" file types that is not supported, and coincidentally one of the only password protected archives I come across (there is this ONE GUY who is convinced 7z is the way of the future) so it was a minor annoyance having to find a new program to open these files.

>>892

Mostly due to it being a lot of work to implement and test. Every part of 7z is horribly over-engineered, and encryption also supports a whole lot of different encryption algorithms that all need to be supported and tested.

Sooner or later I hope to get around to it, but it's not very high priority.

Hi there, great work. The Unarchiver is one of the programs I use the most in my daily life. Tremendously useful. However, even though it is incredibly unlikely, have you ever considered adding support for .uha files? I know they are stupid and arbitrary, but I came across some today that I need to open, and no application on Mac OS X can do it. I figured others might occasionally like to open these too.

Assuming the compression is relatively simple, what are the chances of seeing this feature? It would certainly give The Unarchiver added appeal, being the only program able to tackle .uhas.

Cheers,
Franklint

>>894

Depends a lot on whether the format is documented (and how complicated it is), and if it is in use anywhere in particular.

hey !WAHa.06x36 and everyone else.

can someone confirm that by unarchiving the file below, the executable inside 'contents > macos' loses the execute flag and the app doesn't launch?
i confirmed decompressing it with path finder's built-in stuffit engine and it retains the flag but not with the unarchiver.
with path finder it's also easy to set the execute flag back on, just wondering if it's just me.

thanks.

grafx2 (grafx2-2.3wip.1755-macosx.zip or latest release)

http://code.google.com/p/grafx2/downloads/list?can=2&q=label%3AOpSys-OSX

>>896

That's caused by a buggy archiver. 2.7 will have better code to deal with it, but report it to the grafx2 people so they can report it to whoever made the archiver they are using. I still haven't found out which archiver it is that creates these broken archives.

thanks man. i will ask and report.

>>897

ok, it figures, it's 7zip. franck, who did the packaging for the mac version of grafx2, used the original 7zip on a windows box, not one of the mac flavored 7zip versions (7zX, keka, Ez7z).

it's ok, this just happens once in a while and i can easily set the execute flag back on. just now we know, 7zip did it.

Is The Unarchiver capable of unzipping ZIPs larger than 4GB? I'm getting an error with a 7.2GB ZIP, that Mac OS X's native Archive Utility can unzip fine.

>>899

Ah, yes, that'd explain it. Basically, Archive Utility will mark all files executable if there's no information specifying otherwise.

>>900

It should be, but most programs produce invalid zip files for data larger than 4GB, so unarchiving programs have to try and compensate to get the data out. Which version are you using?

>>902

Like I said, it should work better in 2.7, and in the meanwhile, report it to Blizzard. The zip tool they are using is the actual problem.

(for your information only)

>>901

franck went ahead and published the new grafx2 version (and future ones, i hope) in a standard .tgz which keeps execution bit attributes preserved.

http://code.google.com/p/grafx2/downloads/detail?name=grafx2-svn1759-macosx.tgz&can=2&q=label%3AOpSys-OSX

>>902

even if we are lucky that !WAHa.06x36 fixes these issues for us, devs who distribute files for mac should use a mac compliant app to archive them, but i guess it's normal they don't know about the architecture of bundles and attributes on this platform.

I'm sorry, I don't understand what to do with the binaries to compile anything for Windows.
The Unarchiver is such an extraordinary tool for everyday use, it's one of the things I miss the most when I'm working on a PC.
Do you think it's possible to put a version out there for windows users ?

Thanks a lot for that incredible work !!

>>895
It doesn't seem well-documented at all - I can't find anything much on its technical specs, only that it is typically more efficient than .zip and .rar. It seems to have a niche following though, so it'll be up to you whether it is in use enough to merit support. Just a suggestion, and I managed to decompress my own files in any case. Thanks for The Unarchiver man, regardless of whether you take up my suggestion :).

Cheers,
Franklint

Have downloaded a file in two parts. When attempting to expand I get the attached message. How do I put the two parts together before expanding or hiow do I get past the error message???

I am trying to use The Unarchiver to read a ZIP file produced by 7-zip which is AES-256 encrypted. Unarchiver recognizes the file, opens it, and prompts me for the password. When I enter the correct password, it tells me each file in the archive is corrupted.

Suggestions?

>>908

File a bug on the bug tracker, including the file and correct password.

Well, I finally got it sorted out. There's a new version now, and it's available on the App Store.

http://itunes.apple.com/app/the-unarchiver/id425424353

If you can't or don't want to use the App Store, it's still available normally:

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

The direct download version is still 32-bit x86 and PPC. The Mac App Store version is 32-bit and 64-bit x86. I'm going to put up the App Store version for direct download too later.

Other updates:

• Support for ISO and BIN disc images.
• Support for encrypted StuffIt archives, thanks to a friendly archivist.
• Workaround for broken Zip archives that make files non-executable.
• Fixed unpacking .pkg files.
• Better StuffIt X support.
• Other bugfixes.

The unar and lsar command-line utilities have been updated too:

http://theunarchiver.googlecode.com/files/unar0.4.zip
http://theunarchiver.googlecode.com/files/unar0.4_win.zip

The Windows version hopefully includes all the required DLLs this time.

Is there a reason the app is only available in the U.S. App Store?

Well, here's the 64-bit App Store version for anyone who wants it, but can't use the App Store:

http://theunarchiver.googlecode.com/files/TheUnarchiver2.7_64bit.zip

>>912

Is it? I can see it in Finland. Where can you not see it?

>>910
I have tried TheUnarchiver2.7 on PPC G3 and G4 running 10.4.11

Every time TheUnarchiver2.7 will start to unarchive a file, but it never finishes and I need to force quit it.
SHA1 is correct.

Console log:
2011-04-17 10:36:35.561 The Unarchiver[760] *** -[NSFileManager contentsOfDirectoryAtPath:error:]: selector not recognized [self = 0x507c00]
2011-04-17 10:36:35.562 The Unarchiver[760] *** NSThread: ignoring exception '*** -[NSFileManager contentsOfDirectoryAtPath:error:]: selector not recognized [self = 0x507c00]' that raised during delayed perform of target 0x596290 and selector 'extractFinished'

No problem with TheUnarchiver2.6

Any suggestions?

I have exactly the same proble as >>910. So far have attempted to unarchive two fairly large archives (over 300MB), and when it gets to the part where it has to make the tempfolder visible, set the permissions, whatever, it hangs, leaving the Unarchiver window open and permanently present (the X won't kill it). It does get far enough so the progress bar becomes steady Aqua (not pulsating), But I have to go to the Activity Monitor to kill it, and, of course, this leaves invisible and sometimes hard to find GIANT folders behind. It appears to do a good job of unpacking, but only an experienced user will be able to find the files and quit the program window.

I'm not certain if other file tasks are being completed, since the archives I used consisted of multi-thousands of small documents (txt, png, jpg, cvx, eps, ai, etc.). After moving the invisible folders to the desktop and making them visible, they look fine, and taking a random sampling, they all open without any sign of corruption... but with this many files, I have no idea if any were skipped, corrupted, or if naming and permissions were done correctly.

Another note, once it has been force quit, I cannot get it to relaunch properly until I reboot. If an attempt is made to open an archive that is supported, nothing happens. So force quitting IS NOT a valid method of terminating the program.

>>915-916

10.4 is accidentally not supported. Use 2.6 until it gets fixed.

>>916
If you use Unarchiver 2.6 on those files that failed with version 2.7
the invisible files will be "deleted". No need to find and delete.

2.7.1 is now available, and should hopefully fix compatibility with 10.4 and maybe even 10.3.9:

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

That is the only change. Anybody on a newer version does not need to update, and there is no update for the Mac App Store version, as it does not work on 10.4 in the first place.

>>914

Not available in the Australian Mac App Store. :(

>>920

Complain to Apple. The App Store seems kind of buggy.

Hi,
Downloaded it from canadian app store. Say installed but can't find it anywhere???

/usr/bin/ld: libXADMaster.a(CSZlibHandle.o): undefined reference to symbol 'inflateInit2_'
/usr/bin/ld: note: 'inflateInit2_' is defined in DSO //usr/lib/libz.so.1 so try adding it to the linker command line
//usr/lib/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [unar] Error 1

>>922

It should install just the same as any other App Store app. If it doesn't, complain to Apple.

>>923

What exactly are you doing? And is your libz installation really working right?

I followed the instructions, running make -f Makefile.linux. Debian doesn't have a libz package. It has a zlib1g-dev package that provides libz-dev.

>>923

Kete, you need to add "-lz" to the LIBS variable in XADMaster/Makefile.linux.

I'm in the process of creating a Debian package of The Unarchiver. You can find out more at http://bugs.debian.org/619602.

Matt, I don't know how to do that, tried LIBS=-lg
Godspeed (on the package)

>>927

Kete, you should be able to download a fixed XADMaster/Makefile.linux from https://theunarchiver.googlecode.com/hg/XADMaster/Makefile.linux.

>>915 >>919
Recently I was given an iBook G3 with 10.3.9

It seems Unarchiver version 2.x.x is NOT compatible with 10.3.9
They all fail the same way. Do you want the crash.log's?

The Unarchiver271.crash.log
The Unarchiver260.crash.log
The Unarchiver250.crash.log
The Unarchiver240.crash.log
The Unarchiver230.crash.log

Unarchiver161 works on a G3 with 10.3.9

Unarchiver271 works on a G3 with 10.4.11

-Bill

>>929

I guess it doesn't work on 10.3.9, then. I can't really do much about that, other than accept a patch if anyone figures out how to make it run.

>>928
Thanks, Matt, that worked without error, but I don't see where to go from here (sorry!).

I have recently encountered some weird behavior form this great app.
I will click on a .zip, .rar, ect file and it will do it's thing.
BUT I have to back out of that folder then go back into it in order for the items to reveal themselves?
I hope I'm explaining this well enough for some to understand me.
Might anyone have thoughts on how to correct this?
I did uninstall then reinstall....
no luck.
Thanks in advance

>>932

It has to do with the NFS (unix "nightmare file system") setup used on most LAMP webservers. It's none of your own fault. Trust me; I use a linux box for my home and business computings...

Have a nice day.

>>933

Shoot, just realized we weren't talking about LAMP software here! lol.

I just was reading an old post of mine on Kareha board installs, and then read this and my mind didn't immediately make the switch heh heh.

Sorry bout the screw up.

>> 932

the reason for your issue is the same, sans the LAMP webserver part. Macs are Unixes for no other reason than Jobs wanted to run the new NEXT/Mac on a Unix architecture, so he utilized the nightmare filesystem.

Besides Linux/BSD/Unix/Mac FS's being a load of cow crap, everything else in their makeup is far better than Windows, IMO. I could smash glass anyday, but give me a Linbox and I'd marry it on the spot (not being literal here).

Have fun. Hope this helps!

Won't help as a quick-fix for OS X native unarchiving. Why? This download can't unarchive itself!!!! You are not thinking! How can you put an unarchiving utility in an archive????? Duh!!!

>>931

Kete, you should now have lsar and unar executables. They should run correctly if built in wheezy (aka testing) instead of sid (aka unstable).

hi, when we have unarchiver on official debian packages?

>>937

I don't know; there are toolchain problems that prevent uploading to unstable yet.

In the meantime, you can download a Debian source package from http://anonscm.debian.org/gitweb/?p=collab-maint/theunarchiver.git;a=summary which you should be able to build in testing.

>>932

This is a Finder problem which I'm not aware of any workaround for. The answer given in >>934 is completely incorrect.

Any hope of being able to unarchive .kgb files

>>940

Depends. Apparently it is actually somewhat documented, so it would be possible, but I don't know if it is in wide enough use to be worth the effort.

>>940

Looking a bit closer into it, KGB is based on PAQ6, which is GPL licensed, and thus cannot be included in The Unarchiver, which is LGPL. Adding support would require the author of PAQ changing his license to LGPL.

Okay, thanks, Matt, I'm finally lsaring and uraring.

I'm a beginner here so I may be asking a dumb question, please bear with me as I've not been able to find an answer anywhere else.
I zipped a large folder of files to save space on a laptop (zipped, about 5GB) using the built-in function in Windows XP. I changed the name of the zip file - from something like xyz_123.zip to 1.zip. Now XP's inbuilt extract says that the archive is 'incomplete' or 'corrupted'. I've tried various other programs (7-zip, Winzip, etc) without success. I moved the archive over to my iMac (10.6.) and tried Stuffit Expander also without success. I then discovered The Unarchiver and tried it: It started to work and extracted about 10% of the files before failing with "Error during decrunching".
Any ideas?
The only thing I can think of: is it a bad move to change the name of a .zip archive? Is the name also internally-coded so that both must be the same?
cheers, and thanks in advance if you answer my questions.

When downloading from the Mac App Store, the application appears to install and then reverts back to the "Install" button and without the application appearing in the Applications folder. If you look under purchases, there is an "Install" button beside the application.

>>945

It is possible that XP's built-in archiver doesn't support archives more than 4 GB and actually broke the archive while making it.

>>946

That would be an App Store bug, so report it to Apple.

I clone the theunarchiver repository hosted at Google Code and I compiled on my GNU/Linux Fedora 15 box

$ make -f Makefile.linux
gcc -std=gnu99 -c -O2 -Wno-import -Wno-multichar -g -D_FILE_OFFSET_BITS=64 -isystem /usr/include/GNUstep -DGNUSTEP -DGNU_RUNTIME=1 -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime -fexceptions -fobjc-exceptions -fconstant-string-class=NSConstantString unar.m -o unar.o
In file included from /usr/include/Foundation/NSClassDescription.h:30:0,

             from /usr/include/Foundation/Foundation.h:50,
             from XADUnarchiver.h:1,
             from unar.m:1:

/usr/include/Foundation/NSException.h:42:2: error: #error The current setting for native-objc-exceptions does not match that of gnustep-base ... please correct this.

Searching on the web, I found a workaround for this problem [1] by changing the line

#define BASE_NATIVE_OBJC_EXCEPTIONS 0

from /usr/include/GNUstepBase/GSConfig.h into

#define BASE_NATIVE_OBJC_EXCEPTIONS 1

The next message error was

gcc -Wl,--whole-archive -fexceptions -fgnu-runtime -o unar unar.o CSCommandLineParser.o CommandLineCommon.o NSStringPrinting.o libXADMaster.a ../UniversalDetector/libUniversalDetector.a -Wl,--no-whole-archive -lgnustep-base -lcrypto -lbz2 -licuuc -lobjc -lstdc++ -lm
/usr/bin/ld: libXADMaster.a(CSZlibHandle.o): undefined reference to symbol 'inflateInit2_'
/usr/bin/ld: note: 'inflateInit2_' is defined in DSO /lib/libz.so.1 so try adding it to the linker command line
/lib/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [unar] Error 1

as stated [2] and [3] I fixed this by adding -lz ([3] comments that Fedora have a setting preventing gcc of
implicit linking.)

OK, after that I've got lsar and unar binaries. Great !

However, I've found there I've got this problem descompressing rar files (both with lsar and unar):

$ ./lsar ~/Desktop/example.rar
/home/jjmarin/Desktop/Evince/example.rar :
1.jpg
2.jpg
./lsar: Uncaught exception CSEndOfFileException, reason: Attempted to read past the end of file "/home/jjmarin/Desktop/Evince/example.rar" (XADFileHandle).

Any idea about this ? Has something to do with the BASE_NATIVE_OBJC_EXCEPTIONS change?

Links:
[1] http://www.mail-archive.com/discuss-gnustep@gnu.org/msg12043.html
[2] http://wakaba.c3.cx/sup/kareha.pl/1151796773/l50
[3] http://groups.google.com/group/harbour-devel/browse_thread/thread/1d0c52b293f35c53?pli=1

>>949

You need a GNUStep built with native exceptions enabled, there is no way around this. You'll have to figure out how to get this on your distro. Either by building from source, or by pestering the maintainers until they fix this, most likely.