Well, after a far too long development cycle, The Unarchiver 2.0 is starting to come together. The reason for the massive delay is that huge parts of the internals have been rewritten to make it easier to program and extend. The old libxad is mostly gone except for old formats, and new Objective-C based code handles most normal formats.
Of course, that kind of huge rewrite will have introduced a lot of new bugs, and I really need some help testing it to shake those bugs out. So if you want to help out, you should grab it and try to use it on any files you can find, and report to me if it doesn't work as expected, preferably with the files that cause problems included.
The latest version can be found here:
http://code.google.com/p/theunarchiver/downloads/list
Obviously you should be aware that this may cause all kinds of problems, so be prepared to downgrade in that case.
Further information in later posts. Try to read the thread before reporting bugs!
Found the bug, thanks. It was just a typo in the 7zip permissions code. Should work in the next version.
Thank you! for TheUnarchiver.
I see in your post >>63-69, I searched this site and did not find how to do that. How do you do that and is it useful?
I answered my own question!
Just by typing those in it becomes an active link!
There's also a problem with un-7z-ing folders.
Process starts, but no folder is created.
You're going to have to be more specific, and also supply some example files.
The problem occurs with 7-zip files made with 7zX 1.7.1 (Compression Level Ultra, no password, no other settings) for MacOSX.
If files are compressed in a folder (folder is compressed), the Unarchiver (2.0 beta 4) cannot uncompress the folder, but 7zX can.
With the Unarchiver, the process starts, but no folder is created.
Free files uncompress properly but have the above mentioned permissions error (User has no read or write privileges).
I'm not sure if this is a problem with 7zX or the Unarchiver.
Test file: http://www.mediafire.com/?ydjgz2k2zgn
This is just the same problem with permissions, which is fixed in the development version.
Would be nice if 2.0 also could support the XZ-format (.xz, .tar.xz, .txz), successor of the LZMA-utils <http://tukaani.org/xz/>. While still marked as beta it's already supportet by gnu tar 1.22 and AFAIK XZ-utils are backwards compatible with LZMA-utils and could replace the lzma part.
It'll probably be supported, but more likely in 2.1 than 2.0. The XZ format is apparently kind of an overengineered mess and would take some work to support.
(Also, what happened to the other formats that adopted the format while it was still called LZMA-utils, like RPM 5 and XAR? Is the finished XZ format still compatible with those files? Or is there some intermediate version that I'd need to support too?)
xar 1.6 supports lzma as well as xz. Didn't ever use RPM5. As I read the docs, the xz-format itself is officially stable. Don't know how to implement support for new formats in TUnA, just thougt it could be as easy as replacing liblzma from LZMA-utils with the version from XZ-utils and add the xz extensions to info.plist...
If it's a heavier task to implement, don't hurry. Can easily be solved using Terminal.
I use as few external libraries as possible, most things are implemented from scratch. Most libraries don't fit the programming model the XADMaster framework uses anyway.
Anyway, the problem is that there are two formats called ".lzma" - the one implemented by the old LZMA-utils, and the new one implemented only by beta LZMA-utils, which was then turned into XZ. However, several formats seem to have adopted the beta LZMA-utils format, and now I don't know if that is the same as what XZ ended up being or not.
To make it more confusing, it seems XAR supported BOTH the old and new LZMA formats under the same name, so does it now have a THIRD lzma format with a new name?
From xar --help output:
--compression Specifies the compression type to use.
Valid values: none, gzip, bzip2, lzma, xz
Default: gzipDon't know internals about the differences in formats/encoders but you could ask directly in the lzma/xz-utils forum:
http://sourceforge.net/forum/forum.php?forum_id=708858
I can only say, I use the xz-utils here and never had an issue with unpacking any lzma-file.
All right, this seems to be good enough for a real release now, so it's time for a release candidate. If nobody reports any more bugs for this version, or submits any more translations, it will be relabeled and officially released as 2.0 in a couple of days.
http://theunarchiver.googlecode.com/files/TheUnarchiver2.0RC.zip
TheUnarchiver rocks, great work! Can you add (or is it already there) a way to choose the destination for one archive? Like by default extract to the same folder but if it is open with option held down then ask for the destination?
Can one day TheUnarchiver became The(Un)Archiver, by adding the possibility to compress files, maybe just really supporting a open format like 7z or xar?
>>72 is fixed.
I downloaded the compiled binary for 7za and also downloaded the source.
The source folder has some tests, some of which The Unarchiver 2.0 RC fails.
7za will extract all, including the password protected files.
password="qwerty"
Are these known issues?
p7zip 9.04.dmg
kMDItemWhereFroms = (
"http://web.me.com/krmathis/applications/p7zip%209.04.dmg",
"http://web.me.com/krmathis/"p7zip_9.04_src_all.tar.bz2
kMDItemWhereFroms = (
"http://softlayer.dl.sourceforge.net/project/p7zip/p7zip/9.04/p7zip_9.04_src_all.tar.bz2",
"http://sourceforge.net/projects/p7zip/files/p7zip/9.04/p7zip_9.04_src_all.tar.bz2/download"Tests done with The Unarchiver 2.0 RC:
The Unarchiver 2.0 RC does NOT expand:
7za.exe.lzma86
7za.exe.xz
7za433_7zip_lzma_crypto.7z
7za433_7zip_lzma2_bcj2.7z
7za433_7zip_lzma2_crypto.7z
7za433_7zip_lzma2.7z
The Unarchiver 2.0 RC expands ok:
7za.exe.lzma
7za.exe.lzma_eos
7za433_7zip_bzip2.7z
7za433_7zip_lzma_bcj2.7z
7za433_7zip_lzma.7z
7za433_7zip_ppmd_bcj2.7z
7za433_7zip_ppmd.7z
7za433_tar.tar
I could find only two .sitx files on my Mac and both extracted with The Unarchiver 2.0 RC. I re-compressed them as .zip Now no more .sitx files!
> Can one day TheUnarchiver became The(Un)Archiver
I hope not.
Unarchiving and archiving are two mostly unrelated tasks, and I don't think it's a good idea to combine both in one app.
I do have some ideas for an archiver, but it would involve some pretty crazy ideas which would take a lot of work to turn into reality, so it may never happen.
(Also, neither 7-zip nor XAR are particularly open formats. Neither is has a proper spec published, and are only defined through source code - mostly uncommented and hard to read in the case of 7-zip. Zip is far more open than either of those.)
Well, the first attempt at a release candidate failed. Let's try again!
http://theunarchiver.googlecode.com/files/TheUnarchiver2.0RC2.zip
All right, 2.0 is now released.
http://theunarchiver.googlecode.com/files/TheUnarchiver2.0.zip
This thread is now over, and any further discussion can return to the main thread at http://wakaba.c3.cx/sup/kareha.pl/1151796773/.