GNOME Bugzilla – Bug 646606
Use 'unar' rather than 'unrar' to extract RAR files
Last modified: 2012-07-09 15:27:30 UTC
unar is the command interface for The Unarchiver (http://wakaba.c3.cx/s/apps/unarchiver.html) and supports extracting .rar archives with a free implementation (unlike rarlab's unrar) and with support for RARv3 (unlike Gna unrar). Please consider checking for 'unar' when extracting a .rar archive :)
I can't make any promises, but I'm really tempted to take a shot at adding this support.
Just want to say I am actively (well, as free time permits) trying to implement FrCommandUnar. It's not 100% straightforward, because there are minor improvements or changes needed to The Unarchiver's command line utilities, lsar and unar. Mainly I'm thinking the robustness of error reporting, and how well multi-part RAR archives are handled (or how I should handle them). The good news is that these things are fixable, and the maintainer of The Unarchiver is helpful. I think the support in File Roller will have to be optional at compile time. The lsar utility outputs file information in JSON. This is a good thing, because it means we can better support perverse archives which contain files with newlines in their filenames. But it does mean a dependency on json-glib, which isn't an external dep for GNOME.
Hi Paolo, Could you please explain to me the meaning of the bool comm->propCanExtractNonEmptyFolders? I'm really struggling to work out how and why archive_type_has_issues_extracting_non_empty_folders () is used in fr-archive.c. As a reminder, only FrCommandTar "has_issues_extracting_non_empty_folders". I ask because I'm setting comm->propCanExtractAll = TRUE for "unar", because it supports extract all. In fact, at the moment, unar can ONLY do extract all. As an *interim* measure I had assumed that I could set comm->propCanExtractNonEmptyFolders to FALSE. Then I thought File Roller might emulate extracting selected files from an archive by extracting all to a temp folder, then only copying across the relevant files. This sometimes works as I'd expected. In particular, I set comm->propExtractCanJunkPaths = FALSE. When I extract and tell File Roller to junk paths, it has to emulate path junking. First it does the extraction to a temp folder, and then it happens to only copy across the files I'm interested in. But if I don't tell File Roller to junk paths, no temp folder is used and all files are extracted. So I think I misunderstand the purpose of the propCanExtractNonEmptyFolders flag. Thanks.
propCanExtractNonEmptyFolders is used to overcome an issue with tar archives, for example if the content of a tar archive is readme.txt doc/ doc/page1.html doc/page2.html and you want to extract the content of the doc folder, the command: tar -xf archive.tar doc doc/page1.html doc/page2.html gives an error. To fix the issue you have to remove the files inside the doc folder from the command line, getting the following command: tar -xf archive.tar doc It's likely that unar doesn't have this issue, so propCanExtractNonEmptyFolders must be set to TRUE (or just don't set it, because TRUE is the default value set by the base class FrCommand).
Just thought it might be useful to add that The Unarchiver has recently been accepted into Debian Main (see http://packages.debian.org/sid/theunarchiver), which might help development. Matt Kraai, Asias He and Julián Moreno Patiño are the maintainers over there. This will probably trickle down to all the Debian based distros, so demand for this will increase. Personally, I would love to see this happen.
It looks like the unar utility doesn't have the ability to list the content of the archive (correct me if I'm wrong). This makes problematic adding support for it, as we could be forced to extract the content of the archive just to show the list of files it contains, which is suboptiomal to say the least.
See comment 2: lsar is shipped with unar. Isn't lsar suitable for the task?
(In reply to comment #7) > See comment 2: lsar is shipped with unar. > Isn't lsar suitable for the task? Indeed it is. lsar even supports JSON, which IMO allows us to write a more reliable parser for its output (compared to having to parse whitespace information). I had some working file roller lsar/unar code, but I got completely distracted by other things. . . Let me make it build again, then I'll make sure I at least upload it here. Please somebody ping me if I forget. But the (unpolished) file roller code wasn't the hard part. There may be some polish still needed in lsar/unar itself.
Iain: I'm curious what kind of progress your fileroller lsar/unrar code is getting.
What are the odds of getting this for 3.6?
The support for the unarchiver utility has been added in the current development version. This feature will be available in the next major release (version 3.6).