unrar-free fails on all my rar-files

Bug #311291 reported by Boombofer
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
unrar-free (Debian)
Fix Released
Unknown
unrar-free (Fedora)
Won't Fix
Medium
unrar-free (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: unrar-free

Ubuntu 8.10

unrar-free:
  Installiert: 1:0.0.1+cvs20071127-1
  Kandidat: 1:0.0.1+cvs20071127-1
  Versions-Tabelle:
 *** 1:0.0.1+cvs20071127-1 0
        500 http://de.archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

Description:
unrar-free isn't able to extract my rar-files (this came with an update I think)

What I did for testing:

michael@thinkpad:~/unrar-test$ echo 'hello' test
hello test
michael@thinkpad:~/unrar-test$ echo 'hello' > test
michael@thinkpad:~/unrar-test$ rar a test.rar test

RAR 3.80 beta 2 Copyright (c) 1993-2008 Alexander Roshal 16 Jun 2008
Shareware version Type RAR -? for help

Evaluation copy. Please register.

Creating archive test.rar

Adding test OK
Done
michael@thinkpad:~/unrar-test$ rm test
michael@thinkpad:~/unrar-test$ unrar-free -x test.rar

unrar 0.0.1 Copyright (C) 2004 Ben Asselstine, Jeroen Dekkers

Extracting from /home/michael/unrar-test/test.rar

Extracting test Failed
1 Failed

Revision history for this message
In , Browaeys-alban (browaeys-alban) wrote : Re: Bug #312552 - Obsolete package

SI unrar-free unamintained upstream ? I don't think so there have been
 contribution from mplayer a few monthes ago.

http://www.unrarlib.org/faq.html
"What about RAR 3 support?

RAR3 support is not scheduled. It would imply problems with the GPL license (RAR3 features a PPM based compression algorithm developed by Dmitry Shkarin plus some code by Eugeny Roshal).
If you need RAR3 support, check ftp.rarabs.com for the original unrar source code and extract the needed code yourself.
Windows developers may have a look at Sebastian Schuberth's "arch::ifstream" library (requires the unrar.dll).

If YOU added RAR3 support and would like to share it with the 2000 monthly visitors of this page, so please let me know."

with :

"Do you know that the license for the unrar sources from RARLab is not compatible with the GNU Public license?
Yes, this is true. But we have the permission from Eugene Roshal to release unrarlib 0.4.0 under GPL and unrarlib-license. Note: this doen't mean that RAR is free now or you can use the unrar source from RARlabs under GPL. You are just allowed to use UniquE RAR File Library version 0.4.0 (unrarlib 0.4.0) under GPL."

I don't get what is the meaning of :
"It would imply problems with the GPL license (RAR3 features a PPM based compression algorithm developed by Dmitry Shkarin plus some code by Eugeny Roshal)."
Does it means the only way they believe they could had support for rar3 is by taking the
rar3 code from non free upstream ?

From the second stance i conclude that there never was a development team for the
 decompression algorythm.
unrarlib looks like a library wrapper around a port of a "given" rar2 core.
Which is useless now for debian rar users.

The submitter :
"But sarge, etch and sid have rar >3.x, so...it produce newer archve."
tells it all. The compression tool is provided freely though the decompression one won't.

So it looks like the library is of some use if a program want to use rar2 as its internal storage
format but ithe unrar tool is useless to users ... unrar-free could be of some use to programs that
cannot use the c library , shell scripts ...

Should we remove it or tag it as developper only in the README (and maybe ship it in /usr/lib so that it does not conflict with the "user" unrar-nonfree ) ?

Regards
Alban

Revision history for this message
In , Ying-Chun Liu (paulliu) wrote :

Subject: Re: Bug #312552 - Obsolete package
Followup-For: Bug #312552
Package: unrar-free
Version: 1:0.0.1-2

*** Please type your report below this line ***

It is USABLE.

I don't use non-free softwares.
Therefore, I don't use the non-free rar 3.x.
This package at least provides the ability
to decompress *some* rar files on internet.

-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)

Versions of packages unrar-free depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an

-- no debconf information

Revision history for this message
In , Ying-Chun Liu (paulliu) wrote : unrar-free: request for RAR 3.0 format support

retitle unrar-free: request for RAR 3.0 format support
severity wishlist

Thanks for investigation. The main problem is we need the support for
RAR 3.0 archives. We believe that this bug is not a serious one because
it still works in some RAR 2.0 format archives. unrar-free now is not a
replacement nor a conflict to unrar-nonfree. And according to the
statistic data in popularity contest, it is still worth to keep it in main.

--
                                                PaulLiu(Ying-Chun Liu)
E-mail address:<email address hidden>

Revision history for this message
In , Ying-Chun Liu (paulliu) wrote : 312552

severity 312552 wishlist
retitle 312552 unrar-free: request for RAR 3.0 format support

--
                                                PaulLiu(劉穎駿)
E-mail address:<email address hidden>

Revision history for this message
In , Ying-Chun Liu (paulliu) wrote : Partially fixed

Hi,

This bug is partially fixed. With version >= 1:0.0.1+cvs20070424-1, it
is possible to decompress some portion of RARv3 format. Currently,
one-volume, unencrypted, small archives can be decompressed easily. The
AES-cipher introduced by RARv3 is still not supported. And large-file
support is lacking, either. But it do decompress many RAR files now.

Many Thanks,
 Ying-Chun Liu
--
                                                PaulLiu(劉穎駿)
E-mail address: <email address hidden>

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

Spec URL: http://sundaram.fedorapeople.org/unrar.spec
SRPM URL: http://sundaram.fedorapeople.org/unrar-0.0.1-1.20070515cvs.src.rpm

Description:
unrar is a free software RAR archive extractor. It uses the GPL'd
UniquE RAR Library by Christian Scheurer and Johannes Winkelmann.
unrar is a simple command-line front-end to this library, and can list
and extract RAR archives.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :
Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Weird; this package builds fine in mock but when I tried to build it on a
rawhide machine outside of mock it failed:

+ /usr/lib/rpm/find-debuginfo.sh /tmp/unrar-0.0.1
extracting debug info from
/var/tmp/unrar-0.0.1-1.20070515cvs.fc8-root-tibbs/usr/bin/unrar
Only dest dir longer than base dir not supported
error: Bad exit status from /var/tmp/rpm-tmp.28856 (%install)

I've no idea what's up there; perhaps something's gone wrong with that machine.
 It builds OK on an FC5 machine I have around.

You should beware that livna already has a package named "unrar", and I would
urge you to at least let them know that you plan to add a package with the same
name. It has a much higher version number so I expect there to be some level of
user confusion.

It seems to me that because bundling libraries is generally a bad thing, it
would make more sense if the "UniquE RAR Library" were packaged separately and
this package just depended on it. Perhaps that will happen in the future.

* source files match upstream:
   08426f7eafda45cdea6e3928c232c3fc9f81fb5c754996acdfac9d0ece2bf439
   unrar-free_0.0.1+cvs20070515.orig.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none)
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane.
* %check is not present; no test suite upstream. I tried it on a handy rar file
   and it seems to work fine.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

APPROVED

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

New Package CVS Request
=======================
Package Name: unrar
Short Description: 3D Game of Foo
Owners: sundaram
Branches: F-7 EL-4 EL-5
InitialCC:
Cvsextras Commits: yes

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

Correction in description

New Package CVS Request
=======================
Package Name: unrar
Short Description: RAR archive extractor
Owners: sundaram
Branches: F-7 EL-4 EL-5
InitialCC:
Cvsextras Commits: yes

Revision history for this message
In , Ville (ville-redhat-bugs) wrote :

> BuildRoot: %%{_tmppath}/...

Should be

  BuildRoot: %{_tmppath}/...

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :
Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Wow, how'd I miss that one?

Hmm, script checks that the components are there but doesn't care about
syntactic bits like that. I guess I need to hack more.

Revision history for this message
In , Dominik (dominik-redhat-bugs) wrote :

(In reply to comment #2)
[...]
> You should beware that livna already has a package named "unrar", and I would
> urge you to at least let them know that you plan to add a package with the same
> name. It has a much higher version number so I expect there to be some level of
> user confusion.

There will be even more confusion when the users find out that this unrar cannot
unpack their rar archives, because the majority of what's out there is produced
by rar-3.x, which this library cannot handle (it only supports compression
algorithms of rar-2.9x or older).

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

This package opens all the RAR files that I could find so it is certainly useful
for me. The spec is based on Ville's and on this package has been submitted here
based on his request. Feel free to engage in a debate on list about the
pros/cons of this software elsewhere and let's focus on packaging here.

Revision history for this message
In , Mamoru (mamoru-redhat-bugs) wrote :

(In reply to comment #2)

> You should beware that livna already has a package named "unrar", and I would
> urge you to at least let them know that you plan to add a package with the same
> name. It has a much higher version number so I expect there to be some level of
> user confusion.

For this issue, how do you think about making this (Fedora's) new
unrar have "Epoch 1"?

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

(In reply to comment #10)
> (In reply to comment #2)
>
> > You should beware that livna already has a package named "unrar", and I would
> > urge you to at least let them know that you plan to add a package with the same
> > name. It has a much higher version number so I expect there to be some level of
> > user confusion.
>
> For this issue, how do you think about making this (Fedora's) new
> unrar have "Epoch 1"?

Using an Epoch seems like a big kludge. :|

If we can get the Livna and Fedora maintainers cooperating about
naming/versioning, we can skip the Epoch necessity altogether. Not sure how
feasible such cooperation would be though, from a technical standpoint...

Revision history for this message
In , Ville (ville-redhat-bugs) wrote :

In the rare cases where I've needed unrar, this particular version of it has
done the job just fine. I don't know what version of rar have those files been
compressed with though.

But anyway, I don't think Epoch would be a good solution as this one is
allegedly an inferior implementation in functionality compared to the non-free
one; just leave things as is. That way people who need the non-free unrar and
use repositories that ship it can just upgrade to it and this package won't
stand in the way.

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Other possibilities are to simply rename this package to "unrar-free" or to
coordinate a rename of the livna package to "unrar-nonfree" with the Fedora
release and simply not push this package to F7.

Revision history for this message
In , Ville (ville-redhat-bugs) wrote :

Sure, but I can't think of a reason offhand why someone would want both this and
the nonfree unrar installed, nor what else the -free and -nonfree suffixes would
be useful for.

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Well, the utility seems obvious to me: solves the issue of having a package in
livna with the same name as a package in Fedora.

Revision history for this message
In , Ville (ville-redhat-bugs) wrote :

Maybe it's just me, but I don't think that's a problem that really needs to be
solved in this particular case. And it's not even clear that an unrar package
will be shipped in Livna after this is in Fedora (it's unmaintained there
already). But if Livna drops it, Epoch bump would be appropriate here. Just my
.02€, feel free to proceed as you wish.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

Perhaps it's worth pinging the fedora-devel and/or livna freeworld lists before
importing this to see if anyone has any better solutions to co-existance of the
two packages. Given comment #16 it sounds like it might not be in livna too much
longer anyhow...

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

Uh, looking at the code in the SRPM, this appears to be the same code used in
clamav. The legal status of that code is not clear to me. (In fact, I
considered bringing this up with respect to clamav, but seeing the same code
used in another package makes this all the more urgent.) The file headers
say: "This code is based on the work of Alexander L. Roshal". But then isn't it
a derived work of the original unrar sources? If it is, it's illegal to
distribute this under the GPL as they're doing because the original unrar
license is non-Free and not GPL-compatible. This (libclamav unrar) code also
has a history of sharing the security vulnerabilities of the non-Free unrar,
which also sounds unlikely for a truely independent implementation. See for
example http://www.securityfocus.com/archive/1/473373/100/0/threaded .

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

From http://www.unrarlib.org/faq.html

Do you know that the license for the unrar sources from RARLab is not compatible
with the GNU Public license?

Yes, this is true. But we have the permission from Eugene Roshal to release
unrarlib 0.4.0 under GPL and unrarlib-license. Note: this doen't mean that RAR
is free now or you can use the unrar source from RARlabs under GPL. You are just
allowed to use UniquE RAR File Library version 0.4.0 (unrarlib 0.4.0) under GPL.

Does that answer you?

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

But this applies to the old RAR v2 only unrarlib. The RAR v3 decompression code
has been added later by the clamav people, and it's that which I'm concerned
about.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

More details would be helpful. Which files implement RARv3 decompression in
unrar that was added by Clamav developers? If this affects Clamav too, you file
a bug report and mark that and this review against Fedora Legal or post to
fedora-legal-list with the details. CC'ing Tom Callaway.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

All the files in http://cvs.gna.org/cvsweb/unrar/src/?cvsroot=unrar which have
newly appeared with the "merge things from unrarlib sourceforge svn, the code
comes from libclamav." commit are suspicious.

libclamav's version of the code is here:
http://svn.clamav.net/websvn/listing.php?repname=clamav-devel&path=%2Ftrunk%2Flibclamav%2Funrar%2F&rev=0&sc=0
First version:
http://svn.clamav.net/websvn/listing.php?repname=clamav-devel&path=%2Ftrunk%2Fclamav-devel%2Flibclamav%2F&rev=1471&sc=1

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

What puzzles me most is this :

Q: There is no way to create a RAR archive with the URARFileLib. When
will you add a "create archive" function?

A: Probably never. The license of the free unrar source code prohibits
making a tool that can create RAR compatible archives.

This restriction would be clearly incompatible with the GPL, so if the source
code was released under "the GNU GPL with the restriction to not use the code to
reverse engineer the process of creating rar archives", then we clearly have a
problem.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

I don't see such a restriction listed out in the actual source code which is
under plain GPL2 or later license. The copyright license in the source package
has a higher legal value over any website.

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

I spoke via email to Eugene Roshal about this issue. He was unaware that clamav
had used derived code from their implementation in clamav, under the GPL
license, and stated that he did not grant them permission to do so.

He said that the only way he was willing for such code to be used was with a
clause like the following:

"The unRAR sources cannot be used to re-create the RAR compression algorithm,
 which is proprietary. Distribution of modified unRAR sources in separate form
 or as a part of other software is permitted, provided that it is clearly
 stated in the documentation and source comments that the code may
 not be used to develop a RAR (WinRAR) compatible archiver."

Unfortunately, such a restriction conflicts directly with the GPL, and is a
showstopper.

This code cannot go into Fedora as is. All RAR v3.x support would need to be
stripped out, before it could be considered. Given that most RAR files are RAR
v3, that severely limits the usefulness of this application.

In addition, we will need to strip the RAR v3 code out of clamav.

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

Have you contacted ClamAV upstream about this already? I'm sure Sourcefire, the
company which now provides the infrastructure for ClamAV and bought most of the
copyrights, will want to know they're distributing illegal code...

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

I just sent them an email (I have a friend who's one of the clamav developers),
and I'm about to poke the clamav maintainer.

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

Bug opened against clamav: 334371

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

Thanks spot for looking into this. Closing this review request.

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

Hmm, couldn't we atleast have a version in Fedora for handling rar v2 files,
because AFAIK unless some special options are checked, rar v3 still produces
files compatible with rar v2, iow it never uses the new rar v3 algorithm's
unless explicitly told too.

I understand that the clamav rar implementation is a no go, but what about
libunrar, if they got permission to release things unfer the GPLv2, then that
should be in the clears, right? Then an unrar based of that without any of the
clamav "fixes" should be fine too, right?

Then we can also fix the name conflict be calling this unrarv2 both the package
and the binary, and teach things which want to use it like mc to first try unrar
and only if that is not present try unrarv2

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

Yep. You could do that.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

We have to patch every program that calls unrar which includes many graphical
archive managers like file roller and ark? That doesn't sound like a good idea
to me.

If the stripped down version of unrar can still open majority of the rar files,
I can continue with importing and maintaining this which I assume is basically
sticking with the same version but we need to find a way to have both the free
and the non-free versions co-exist without patching all the other programs.

Revision history for this message
In , Toshio (toshio-redhat-bugs) wrote :

This has been removed from the cvs repository for now. If you do come up with a
plan to include only OSS pieces in Fedora, please make a new cvsadmin request to
re-add the package.

Rahul, could you add something to http://fedoraproject.org/wiki/ForbiddenItems
to explain the situation with this library?

Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

> If the stripped down version of unrar can still open majority of the rar
> files

The problem is, it can't. :-(

The only reason this version of unrar can decompress most RAR files is that
very RARv3 code which has the licensing issues. Most RAR archives these days
are v3.

Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

(In reply to comment #34)
> > If the stripped down version of unrar can still open majority of the rar
> > files
>
> The problem is, it can't. :-(
>
> The only reason this version of unrar can decompress most RAR files is that
> very RARv3 code which has the licensing issues. Most RAR archives these days
> are v3.

Hmm,

Has anyone actually tested this?

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

Flipping this review to - so it doesn't show up in the report.

Revision history for this message
In , Ville (ville-redhat-bugs) wrote :

FYI: %changelog entry from Enrico's clamav commit in CVS yesterday:

- ship original sources again; unrar is now licensed correctly (no more
  stolen code put under GPL) [...]

...so maybe this package could be resurrected after merging the codebase with
the clamav sources?

Revision history for this message
In , Tom (tom-redhat-bugs) wrote :

No. The unrar license is itself not-permissable for Fedora, and we cannot even
ship the source code, due to clause 6 of the unrar license:

"If you don't agree with terms of the license you must remove UnRAR files from
your storage devices and cease to use the utility."

I would really prefer that upstream clamav pull out libclamunrar*, as there is
no possible universe in which it can be enabled and legally redistributed,
however, in the interim, we need to remove it ourselves. Enrico, can you do
this, or would you like me to handle it?

Revision history for this message
In , Matt Taggart (taggart) wrote : RARv3 format, licensing issues

Hi,

Fedora has also been investigating RARv3 support and licensing issues,
maybe their work would be helpful here?

https://bugzilla.redhat.com/show_bug.cgi?id=319831

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Matt Taggart (matt-lackof) wrote : RARv3 support removed

It looks like the RARv3 support mentioned by PaulLiu on 03 Jul 2007 as
being added in 1:0.0.1+cvs20070424-1 was removed in 1:0.0.1+cvs20071127-1.
Here is the comment from the changelog

"remove RARv3 code from libclamav due to unclear license and patent issues"

So I guess if this bug is "apply the v3 support from libclamav" then the
answer is "wontfix" for now unless they can get the license sorted out, but
if it's meant "to track adding v3 support in general" then it's still open
waiting for someone to implement in an unencumbered manner.

--
Matt Taggart
<email address hidden>

Revision history for this message
In , Matt (matt-redhat-bugs) wrote :

Here is Debian's discussion on the same topic

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312552

It's not clear if the new v3 support mentioned near the bottom is
something different than the encumbered implementation.

The Debian version 1:0.0.1+cvs20071127-1 lists the following in the changelog

"remove RARv3 code from libclamav due to unclear license and patent issues"

so is it now clean again or is there some other issue?

RE comment #32, Debian has switched to using /etc/alternatives for unrar, I
assume fedora could do similar?

If this enough to make it ok for Fedora as well or is there still something I'm
missing?

Revision history for this message
In , Matt (matt-redhat-bugs) wrote :

> It's not clear if the new v3 support mentioned near the bottom is
> something different than the encumbered implementation.

Oops, meant to trim that part, the v3 support mentioned _is_ from libclamav and
is the stuff that was removed in the version mentioned.

Sorry for the confusion.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

Almost all of the files that are available in the wild is compressed using the
new v3 format which is not under a free and open software license. The free
portions are unfortunately pretty much useless as a result and would probably
just serve to cause confusion. If anybody else disagrees, they are free to
submit the non-encumbered portions as a package to Fedora but I won't likely be
taking that effort myself.

Revision history for this message
Boombofer (boombofer) wrote :

Binary package hint: unrar-free

Ubuntu 8.10

unrar-free:
  Installiert: 1:0.0.1+cvs20071127-1
  Kandidat: 1:0.0.1+cvs20071127-1
  Versions-Tabelle:
 *** 1:0.0.1+cvs20071127-1 0
        500 http://de.archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

Description:
unrar-free isn't able to extract my rar-files (this came with an update I think)

What I did for testing:

michael@thinkpad:~/unrar-test$ echo 'hello' test
hello test
michael@thinkpad:~/unrar-test$ echo 'hello' > test
michael@thinkpad:~/unrar-test$ rar a test.rar test

RAR 3.80 beta 2 Copyright (c) 1993-2008 Alexander Roshal 16 Jun 2008
Shareware version Type RAR -? for help

Evaluation copy. Please register.

Creating archive test.rar

Adding test OK
Done
michael@thinkpad:~/unrar-test$ rm test
michael@thinkpad:~/unrar-test$ unrar-free -x test.rar

unrar 0.0.1 Copyright (C) 2004 Ben Asselstine, Jeroen Dekkers

Extracting from /home/michael/unrar-test/test.rar

Extracting test Failed
1 Failed

Revision history for this message
LukeKendall (luke-zeta) wrote :

Same for me after my upgrade to Ubuntu 8.10, doing a similar simple check to the
above.

Installing the non-free unrar allowed the simple test .rar to be unpacked.

luke

Revision history for this message
Juanjo Marín (juanj-marin-deactivatedaccount) wrote :

The hardy unrar-free package works for me, even on intrepid, so something is wrong in the building process of the intrepid package !!!!!!

Changed in unrar-free:
status: New → Confirmed
Revision history for this message
Juanjo Marín (juanj-marin-deactivatedaccount) wrote :

Hardy package is unrar-free_0.0.1+cvs20070515-1_i386.deb and Intrepid is unrar-free_0.0.1+cvs20071127-1_i386.deb.

It seems that the lastest version removes RARv3 code from libclamav due to unclear license and patent issues, so maybe this is the reason because the intrepid package is not as usable as the previous one.

See these links for reference:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312552
https://bugzilla.redhat.com/show_bug.cgi?id=319831
http://packages.qa.debian.org/u/unrar-free.html

Changed in unrar-free:
status: Unknown → Won't Fix
Changed in unrar-free:
status: Unknown → New
Revision history for this message
Jordan Bradley (jordan-w-bradley) wrote :

It's currently broken in Jaunty. I cannot open any rar files. It always says they're corrupted when none of them are. I had to install Alzip through wine.

Revision history for this message
Juanjo Marín (juanj-marin-deactivatedaccount) wrote :

jordanwb,

I don't think so, unrar-free only opens some rar files, though is the only free software which is able to open rar files.

Try the freeware version of rar (sudo apt-get install unrar). Alternativaly, you can install p7zip with the rar pluging (sudo apt-get install p7zip-full p7zip-rar).

You can, of course, use the commercial version of rar (sudo apt-get install rar) -but you must pay for legal use- and you can create rar files. Remember that unrar is not a free format, so I tink is a good idea to avoid its use.

Revision history for this message
Jordan Bradley (jordan-w-bradley) wrote :

Juanjo:

unrar-free used to be able to unrar all my rar files. I had reinstalled Ubuntu to sit on top of Luks and now unrar-free no longer works. On my computer "unrar" is not the freeware version. But I'll try those p7 packages

Revision history for this message
Juanjo Marín (juanj-marin-deactivatedaccount) wrote :

jordanwb:

You're right. The problem is that unrar-free was patched with code from libclamav , but due to unclear license issues it was removed afterward. So this is because unrar-free decompress capability is degraded on recent versions (see references on a previous post).

Revision history for this message
Jordan Bradley (jordan-w-bradley) wrote :

Why did a decompression program include code from a antivirus library? What happened to the "do one thing and do it well" mantra? I looked at the p7zip packages and they're not free either.

Revision history for this message
Juanjo Marín (juanj-marin-deactivatedaccount) wrote :

Well, it was because nobody has done the reversed engineered the rar v3 format. Because libclamav had have documented very well that the code they use was taken from freeware unrar, it was added to unrar-free.

About the p7zip-unrar, of course, it is not free. There is no free-as-freedom software for decompressing the rar v3 format.

Revision history for this message
Ivan Zakharyaschev (imz) wrote :

Can someone please explain how I can tell whether a .rar archive that I've downloaded is a RARv3 archive or it's of an earlier format version?

I encountered an archive which unrar-free fails to extract files from, but I'm not sure whether it would be OK to report it as a separate bug, or it's the same lack of the support for RARv3 archives described here.

$ file ~testing/Загрузки/Eng_Jeeves_Wooster_CD.rar
/home/testing/Загрузки/Eng_Jeeves_Wooster_CD.rar: RAR archive data, v1d, flags: os: Win32
imz@potka:~$

Revision history for this message
Ivan Zakharyaschev (imz) wrote :

Does this output give the information about the version of the RAR-format used?

imz@potka:~$ unrar-free l ~testing/Загрузки/Eng_Jeeves_Wooster_CD.rar

unrar 0.0.1 Copyright (C) 2004 Ben Asselstine, Jeroen Dekkers

RAR archive /home/testing/Загрузки/Eng_Jeeves_Wooster_CD.rar

Pathname/Comment
                  Size Packed Ratio Date Time Attr CRC Meth Ver
-------------------------------------------------------------------------------
 mp3_Jeeves_and_Wooster/01_Extricating_Young_Guissie.mp3
              43021273 39973941 93% 15-08-09 20:13 .....A 1A8AD703 m3? 2.9
 mp3_Jeeves_and_Wooster/02_Jeeves_And_The_Unbidden_Guest.mp3
              42280231 39529190 93% 15-08-09 20:14 .....A 51F97FF9 m3? 2.9
 mp3_Jeeves_and_Wooster/03_Jeeves_And_The_Hard-Boiled_Egg.mp3
              41095317 34576151 84% 15-08-09 20:14 .....A B6C790C5 m3? 2.9
 mp3_Jeeves_and_Wooster/04_The Aunt And The Sluggard - 01.mp3
              55248669 46382815 84% 15-08-09 20:15 .....A B46F06AD m3? 2.9
 ������᪨� � �. �. ���㧮�. ����� � ���.djvu
              13708748 13708748 100% 20-12-10 14:00 .....A 250387BD m0? 2.9
 mp3_Jeeves_and_Wooster
                     0 0 0% 30-12-10 11:23 .D.... 00000000 m0? 2.0
-------------------------------------------------------------------------------
    6 195354238 174170845 89%
imz@potka:~$

Is perhaps the last column the version info?

Shouldn't this be made clear in the documentation?

Revision history for this message
Ivan Zakharyaschev (imz) wrote :

I've downloaded that archive from the links at http://book-download-lib.ru/book/573720-angliyskiy-s-p-g-vudhauzom-d.html .

Changed in unrar-free (Fedora):
importance: Unknown → Medium
Changed in unrar-free (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.