Bug 1083834 - unar: unrar wrapper breaks Ark
unar: unrar wrapper breaks Ark
Status: RESOLVED FIXED
: 1084478 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: Kristyna Streitova
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-03 12:55 UTC by Fabian Vogt
Modified: 2018-03-29 09:44 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2018-03-03 12:55:41 UTC
The wrapper for unrar provided by the unar package breaks Ark.
Ark supports unar directly, but prefers unrar if it's available:

ark.main: Trying to open QUrl("file:///tmp/test.rar")
ark.part: Attempting to open archive "/tmp/test.rar"
ark.kerfuffle: Going to create archive "/tmp/test.rar"
ark.kerfuffle: Checking plugin "kerfuffle_clirar"
ark.kerfuffle: Created read-only interface for "/tmp/test.rar"
ark.kerfuffle: Created read-write interface for "/tmp/test.rar"
ark.clirar: Loaded cli_rar plugin
ark.clirar: Setting up parameters...
ark.kerfuffle: Successfully loaded plugin "kerfuffle_clirar"
ark.kerfuffle: Created archive instance
ark.kerfuffle: LoadJob created
Using the 'xdg-shell-v6' shell integration
ark.main: Entering application loop
ark.kerfuffle: Executing "/usr/bin/unrar" ("vt", "-v", "/tmp/test.rar") within directory "/tmp"
ark.clirar: Failed to detect UNRAR output.
Comment 1 Wolfgang Bauer 2018-03-08 14:36:19 UTC
*** Bug 1084478 has been marked as a duplicate of this bug. ***
Comment 2 Fabian Vogt 2018-03-14 11:34:40 UTC
Ping.
Comment 3 Kristyna Streitova 2018-03-14 15:03:16 UTC
Hello, thanks for your bug report.

The problem is that Ark is trying to use '/usr/bin/unrar' that, in this case, is just a wrapper [1]. As the purpose of this wrapper is to provide just a limited functionality, it can't handle "vt -v" options and it fails. 

I think that at first we should try to make Ark use unar binary if it's available. I'm adding Ark maintainer Luca Beltram to this bug.

@Luca: Would you be please so kind and take a look at it? Thank you!

[1] https://github.com/openSUSE/unrar_wrapper
Comment 4 Luca Beltrame 2018-03-14 16:00:26 UTC
(In reply to Kristyna Streitova from comment #3)
 
> @Luca: Would you be please so kind and take a look at it? Thank you!

I added a downstream patch to Ark which swaps the priorities of "unrar" and "unar": the latter should be preferred now.

https://build.opensuse.org/request/show/587002
Comment 5 Wolfgang Bauer 2018-03-14 16:20:42 UTC
(In reply to Luca Beltrame from comment #4)
> I added a downstream patch to Ark which swaps the priorities of "unrar" and
> "unar": the latter should be preferred now.

I just fear that this will break *creating* rar archives, i.e. using rar if unar is installed... (didn't test that though)

Btw, okular is "broken" as well, it cannot open CBR files any more. (bug#1084478)
This should be fixable by just adding unar support though, which might be a good idea anyway. I'll work on it in the next days.

Just don't understand one thing: what's the point of this wrapper if it doesn't support most options? (and the different output is problematic as well)
And it prevents installing the real unrar too.
Comment 6 Wolfgang Bauer 2018-03-14 17:48:49 UTC
(In reply to Wolfgang Bauer from comment #5)
> I just fear that this will break *creating* rar archives, i.e. using rar if
> unar is installed... (didn't test that though)

And indeed.

I just installed the latest unar and ark (with this patch) on my Leap 42.3 system.
While opening rar archives works now, creating new ones fails with "Adding new files is not supported for this archive" (it worked fine before).

Obviously ark is now preferring the unar plugin for creating RAR archives as well, which is of course read-only.

So basically this patch just replaces one bug with another one. :-/
Comment 7 Fabian Vogt 2018-03-14 18:31:46 UTC
(In reply to Wolfgang Bauer from comment #6)
> (In reply to Wolfgang Bauer from comment #5)
> > I just fear that this will break *creating* rar archives, i.e. using rar if
> > unar is installed... (didn't test that though)
> 
> And indeed.
> 
> I just installed the latest unar and ark (with this patch) on my Leap 42.3
> system.
> While opening rar archives works now, creating new ones fails with "Adding
> new files is not supported for this archive" (it worked fine before).
> 
> Obviously ark is now preferring the unar plugin for creating RAR archives as
> well, which is of course read-only.

Which sounds like a bug. If a plugin is read-only, it shouldn't be chosen for write access.

It might be possible to workaround this in an ugly way and combine unar reading with rar writing in a single plugin...

> So basically this patch just replaces one bug with another one. :-/

A less severe one at least.
Comment 8 Wolfgang Bauer 2018-03-14 18:44:36 UTC
(In reply to Fabian Vogt from comment #7)
> Which sounds like a bug. If a plugin is read-only, it shouldn't be chosen
> for write access.

Sure.
But AFAIK (judging from reading related upstream bug reports recently), this would need a major redesign of ark's internals... 

> > So basically this patch just replaces one bug with another one. :-/
> 
> A less severe one at least.

Agreed.

Personally I still think that unar shouldn't replace unrar if it isn't a drop-in replacement though, which it obviously isn't.
Comment 9 Connor McL 2018-03-14 19:16:27 UTC
I second this that unar should not replace unrar and uninstall it when it is installed.

I found several rar archives that are not compatible with unar and will produce crc and out of bounds read errors, while unrar perfectly extracts them.

It seems unar is not feature complete and not ready to replace unrar. (again, how was it decided that it even should replace unrar?)
Comment 10 Fabian Vogt 2018-03-16 13:40:45 UTC
@kstreitova: I've got a suggestion:

Move the wrapper into a separate package which then provides unrar.

This means for openSUSE, if the non-oss repo is enabled, it'll prefer the actual unrar over the wrapper, but for SLE or the OSS repo only, it'll sill pull the wrapper in.

While this is not the proper solution, it should be done anyway to allow co-installability.

What do you think about that?
Comment 11 Kristyna Streitova 2018-03-19 10:59:02 UTC
(In reply to Wolfgang Bauer from comment #5)
> Just don't understand one thing: what's the point of this wrapper if it
> doesn't support most options? (and the different output is problematic as
> well)

The main reason for this wrapper is a fate request where we want to replace non-free unrar with unar. The purpose of this wrapper is not to simulate all unrar options but just to provide the most used ones for the basic backwards compatibility.

Unfortunately in openSUSE:Factory there are more packages that use unrar and now thanks to your testing it seems that the replacing is not so easy. 


(In reply to Fabian Vogt from comment #10)
> @kstreitova: I've got a suggestion:
> 
> Move the wrapper into a separate package which then provides unrar.

I agree. It seems that in this case, this is our only option how to solve this. I will prepare the package.
Comment 12 Swamp Workflow Management 2018-03-21 16:10:05 UTC
This is an autogenerated message for OBS integration:
This bug (1083834) was mentioned in
https://build.opensuse.org/request/show/589778 Factory / unrar_wrapper
Comment 14 Kristyna Streitova 2018-03-29 09:44:47 UTC
The unrar_wrapper package is in openSUSE:Factory now. I'm closing this bug but feel free to reopen if you encounter any problems again.