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!

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

On OS X you can (normally) just double click a .jar file to run it using the Apple Applet Runner (or whatever it's called). But it's still nice to have the option to extract it.

Time for a bugfix and internationalization release:

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

New in this one:

• More localizations: Portugese and Russian. Thanks this time go to Nylson Coelho and Michael Krekin
• Changed the modifier key for extract-to-foler: Either Shift or Option works now. Command was too easy to accidentially trigger when opening a file with Command-O.
• Fixed a bug where app bundles in StuffIt files would not run correctly after being extracted.
• Fixed a bug where apps would be launched when the open-after-extracting option was on.

Plus the other post-1.2 fixes mentioned earlier.

(Sorry, no fix for the jar association yet.)

can unarchiver open the .sitx(not .sit)?????????? pls??

>>204

Not until somebody reverse-engineers the format.

So, which app handles the .sitx format and can one have it installed without interfering with unarchiver?

The Unarchiver crashes very often when cancelling extraction of sit file :(

>>207

Can you post a CrashReporter log?

Sorry for posting like this, can't provide link at the moment. Copy this and then remove the post. There are more chrash reports in the log, but all look similar; it's always Thread 1 that chrashed in function SIT_UnArchive.

**********

Host Name: franks-ibook
Date/Time: 2006-11-27 21:51:04.620 +0100
OS Version: 10.4.8 (Build 8L127)
Report Version: 4

Command: The Unarchiver
Path: /Applications/Utilities/The Unarchiver.app/Contents/MacOS/The Unarchiver
Parent: WindowServer [7068]

Version: 1.3 (1.3)

PID: 7107
Thread: 1

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfc707aac

Thread 0:
0 libSystem.B.dylib 0x9000ab48 mach_msg_trap + 8
1 libSystem.B.dylib 0x9000aa9c mach_msg + 60
2 com.apple.CoreFoundation 0x907dcb78 __CFRunLoopRun + 832
3 com.apple.CoreFoundation 0x907dc47c CFRunLoopRunSpecific + 268
4 com.apple.HIToolbox 0x93203740 RunCurrentEventLoopInMode + 264
5 com.apple.HIToolbox 0x93202dd4 ReceiveNextEventCommon + 380
6 com.apple.HIToolbox 0x93202c40 BlockUntilNextEventMatchingListInMode + 96
7 com.apple.AppKit 0x93706ae4 _DPSNextEvent + 384
8 com.apple.AppKit 0x937067a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
9 com.apple.AppKit 0x93702cec -[NSApplication run] + 472
10 com.apple.AppKit 0x937f387c NSApplicationMain + 452
11 cx.c3.theunarchiver 0x0000292c _start + 760
12 cx.c3.theunarchiver 0x00002630 start + 48

Thread 1 Crashed:
0 de.dstoecker.xadmaster 0x000b3d84 SIT_UnArchive + 6244
1 de.dstoecker.xadmaster 0x0007a888 xadFileUnArcA + 412
2 de.dstoecker.xadmaster 0x0007a9e0 xadFileUnArc + 240
3 de.dstoecker.xadmaster 0x000bf87c -[XADArchive _extractFileEntry:as:] + 252
4 de.dstoecker.xadmaster 0x000bf75c -[XADArchive _extractEntry:as:] + 540
5 de.dstoecker.xadmaster 0x000bf2f8 -[XADArchive extractEntry:to:overrideWritePermissions:] + 352
6 de.dstoecker.xadmaster 0x000bf0b4 -[XADArchive extractEntries:to:] + 316
7 cx.c3.theunarchiver 0x0000428c -[TUArchiveController extract] + 1052
8 com.apple.Foundation 0x9295d194 forkThreadForFunction + 108
9 libSystem.B.dylib 0x9002b508 _pthread_body + 96

Thread 2:
0 libSystem.B.dylib 0x90049ea8 syscall_thread_switch + 8
1 com.apple.Foundation 0x929755d0 +[NSThread sleepUntilDate:] + 152
2 com.apple.AppKit 0x937a3a10 -[NSUIHeartBeat _heartBeatThread:] + 1100
3 com.apple.Foundation 0x9295d194 forkThreadForFunction + 108
4 libSystem.B.dylib 0x9002b508 _pthread_body + 96

Thread 1 crashed with PPC Thread State 64:
srr0: 0x00000000000b3d84 srr1: 0x000000000000d030 vrsave: 0x0000000000000000

cr: 0x44000244          xer: 0x0000000000000000   lr: 0x00000000000b3c78  ctr: 0x0000000000000003
r0: 0x0000000000000000   r1: 0x00000000f00803a0   r2: 0x00000000fc32cfc4   r3: 0x00000000003daae8
r4: 0x00000000003daae8   r5: 0x000000000000000c   r6: 0x0000000000000007   r7: 0x0000000000000100
r8: 0x0000000000403b59   r9: 0x0000000000000001  r10: 0x0000000000401b55  r11: 0x0000000000000003

r12: 0x0000000090003138 r13: 0x000000000189914c r14: 0x000000000189955c r15: 0x000000000183b200
r16: 0x0000000000080000 r17: 0x0000000000000003 r18: 0x0000000000000001 r19: 0x0000000000000013
r20: 0x0000000000077ab3 r21: 0x000000000455e008 r22: 0x00000000044dd008 r23: 0x00000000044dd00b
r24: 0x0000000000000000 r25: 0x000000000077f008 r26: 0x0000000000000000 r27: 0x0000000000000000
r28: 0x0000000001898c08 r29: 0x0000000000000001 r30: 0x000000000183b200 r31: 0x00000000000b2530

Binary Images Description:

0x1000 -     0x9fff cx.c3.theunarchiver 1.3	/Applications/Utilities/The Unarchiver.app/Contents/MacOS/The Unarchiver

0x29000 - 0x3cfff org.mozilla.universalchardet ??? (1.0) /Applications/Utilities/The Unarchiver.app/Contents/Frameworks/UniversalDetector.framework/Versions/A/UniversalDetector
0x72000 - 0xd1fff de.dstoecker.xadmaster ??? (1.3 (libxad 13.0, modified)) /Applications/Utilities/The Unarchiver.app/Contents/Frameworks/XADMaster.framework/Versions/A/XADMaster
0x8fe00000 - 0x8fe51fff dyld 45.3 /usr/lib/dyld...
...
...

>>209

I'll look into it.

I was so happy to find a replacement to stuffit expander i could not help but make a donation. I hope one day par support is added to the library as no elegant solution exists for os x

>>211

Many thanks! And I'll keep that in mind.

The Unarchiver is a must-have app.:)
Is there a possibility to add a preview-feature like in Zipeg ( http://macupdate.com/info.php/id/23378 )? This would be awesome!:)
Sometimes Unarchiver isn't capable of extracting certain rar-archives (pasword-protected).

Can I help with Dutch localization? I have XCode installed and can open the Unarchiver source code in it but otherwise I'm pretty clueless where to start. Can you give me a quick rundown? Thanks Roland

>>216

I'll add you to the list of translators, and mail you when there's time for a new release.

I'm having an odd problem with TheUnarchiver v1.3 and multi-part RAR files. Some of them work, but on some I get an error saying "the archive file is corrupted." I read on this discussion thread to check the output from Console, and I get this:

KATAMARI.ISO: crc error (f1c77610!=e8ca0330)

However, UnRarX, and WinRAR (run in Parallels) both say the files are fine, and extract them successfully. I've had this happen on archives named with .rar, .r00, etc, and on .part01.rar, .part02.rar, etc archives.

Email me at coredumperror AT gmail if you'd like a sample file that causes this error. I tried creating some small muilti-part archives using different options from WinRAR (authenticity, lock, recovery, etc) but everything worked except the one that I "locked." It didn't give me an error, though; instead TheUnarchiver just opens briefly and closes without extracting anything.

P.S. Is there any way to check which version of TheUnarchiver I have installed? I just downloaded and installed 1.3 to do these tests, but I wasn't sure if I'd had it installed already.

I have installed the app but it does not excute at all. I have a powerbook G4. when I double click the app from Application folder, I understand that I should be getting a "preferences" window but nothinh happens. There is nothing in Console.log. It does not even show up in the activity monitor.

>>219

Are you using 10.4?

Hi!
This program is great! Congratulations!
Do you have a plan to put support .pax and pax.gz files to The Unarchiver?
It would be great!

>>221

I don't have any plan, but I could make one. Depends on how much work it would take, and whether anybody actually uses the format.

>>222

That formats use any install package inside...
.pax.gz: is a standard gzipped .pax file.
.pax: "The pax utility will read, write, and list the members of an archive file, and will copy directory hierarchies. These operations are independent of the specific archive format, and support a wide variety of different archive formats. A list of supported archive formats can be found under the description of the -x option." it's similar to .cpio.

>>223

Now that you mention it, I did see those when taking apart installers. Maybe there is indeed some use for it, then. I'll add it to the list, at the very least, and whenever I have some spare time (don't hold your breath), I'll see what I can do.

>>220

Yes. I am running 10.4.8.

Triede uninstall & reinstall but no go

Thanks,

The Unarchiver 1.3 fails to expand an 85 part RAR archive. RAR Expander handles it OK.

Rar expansion definitely need improvement. ( The new rar version 3.7 is coming out soon )

Is there anyway i can view what is inside the archive without extracting it?
Anyway to know what the filesname(s) that will be extracted?

I know unarchiver is easy to use but sometimes i have to spend time to find out what is actually extracted out from the archive.

>>226

Can't do anything about it without having an archive that shows the problem.

It's time for a small update to The Unarchiver:

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

This has a few requested features and bugfixes, and also experimental support for 10.3! Please try it and tell me if it actually works, because I don't have a machine to test it on. The other changes include:

• Support for pax archives.
• Fixed a bug where large archives with lots of resource forks would cause massive memory use.
• Fixed some timezone-related bugs. Some format may still have problems getting the timestamps exactly right, however.
• Various other minor bugfixes.

Hi,
I just found this great app. Everything works great except Stuffit (.sitx) archives... Will you support this too?
Anyway, thanks! It's very cool!
Dan

>>230

I really, really wish that I could support .sitx, but there is no documentation whatsoever for the format, and nobody's managed to reverse-engineer it yet.

Do you implement the password support for RAR files?

It's planned for 2.0.

Is there a way to get back default system icons for all the archives?

Thanks

>>234

While still using The Unarchiver? You can try finding those icons and copying them over the ones inside the The Unarchiver app bundle.

Feature request: the option to automatically scan the decompressed item for viruses using the virus checking app of your choice. Thanks!

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).

Also, a minor issue with encrypted .sit files - if you enter the wrong password it will try to extract anyway but complain about corruption.

>>237

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!

>>243

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.

>>247

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

>>252

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 :)

>>254

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.)

>>256

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.

>>258

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.

>>260

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.

>>262

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.

>>263

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.

>>264

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

>>266

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...)