GNOME Bugzilla – Bug 707568
file-roller incompatible with rar-5 beta, fails to display contents of rar archives
Last modified: 2013-09-25 18:13:45 UTC
Created attachment 254183 [details] test rar file (contains lorem.txt) When using rar-5.00 beta 8, file-roller fails to show the contents of any .rar file I've tried. No error messages are displayed. After downgrading to rar-4.20, file-roller is able to show the archive contents successfully, and to extract them.
Created attachment 254184 [details] screenshot : using file-roller-3.8.4 and rar-5.00 beta 8 to open test.rar
Created attachment 254185 [details] screenshot : using file-roller-3.8.4 and rar-4.20 to open test.rar
Created attachment 254438 [details] [review] proposed patch, adds support for rar-5 and unrar-5 In rar-5, the "rar v" archive listing format changed. Instead of filename size packed ratio date time attr checksum method version you now have attr size packed ratio date time checksum filename_sometimes_with_trailing_spaces With this patch, file-roller should be able to handle both listing formats. I've tested it on various rars (single and multivolume) with rar-5 and 4.2, and it seems to work.
Also: detecting rar-5 by a "Details:" line in the header may raise some eyebrows, but it's the solution that KDE folks have settled on for Ark (see https://git.reviewboard.kde.org/r/111625/diff/#index_header), and it's probably no worse than attempting to parse rar and unrar version strings.
Hi, I have applied the patch to master, with some minor changes, can you please test the current master version and see if it works for you?
Created attachment 254483 [details] [review] fix unrar-5 detection (In reply to comment #5) Tested by backporting your changes to 3.8 (I don't have a working gnome-3.9 chroot at the moment, and file-roller master requires gtk+-3.9). The only issue I found is that your way of detecting rar version won't work for unrar-5. I've attached a patch to fix that problem.
Thanks for finding this problem, it is fixed in master now, but I had to change your patch because when using unrar you have to change the string passed to sscanf as well.
(In reply to comment #7) > Thanks for finding this problem, it is fixed in master now, but I had to change > your patch because when using unrar you have to change the string passed to > sscanf as well. You didn't need to change it: "RAR %d." is a substring of "UNRAR %d.", so the same sscanf() works for both :) (If you were using Microsofts's sscanf_s(), it would be a different story.)
(In reply to comment #8) I apologize, you are quite right, I had forgotten how sscanf() works :/ I don't know why I had thought that my unrar-5 detection patch worked - probably I had made a mistake in my testing...
(In reply to comment #9) > (In reply to comment #8) > > I apologize, you are quite right, I had forgotten how sscanf() works :/ I don't > know why I had thought that my unrar-5 detection patch worked - probably I had > made a mistake in my testing... I thought the same thing, but some testing proved me wrong :)
*** Bug 707817 has been marked as a duplicate of this bug. ***
*** Bug 708774 has been marked as a duplicate of this bug. ***