GNOME Bugzilla – Bug 757793
file-roller shows additional non-archive entries
Last modified: 2016-04-11 17:15:18 UTC
Created attachment 315098 [details] Demo shot 1/2 Hi! I noticed that for some archives, file-roller (3.16.4) adds an entry with the path of the archive itself to the display. For example, if the archive is opened as $ file-roller ~/Desktop/12dicts-5.0.zip the content display area includes a bogus folder "home" (with fake browsable children). So I can click trough to home <username> Desktop 12dicts-5.0.zip (0 bytes, 1. January 1970) If I do $ cp ~/Desktop/12dicts-5.0.zip /tmp/ $ file-roller /tmp/12dicts-5.0.zip the display will show a folder "tmp" with child "12dicts-5.0.zip" aligning with that theory. unzip confirms that the archive does not actually "contain itself": $ unzip -l ~/Desktop/12dicts-5.0.zip Archive: /home/.../Desktop/12dicts-5.0.zip Length Date Time Name --------- ---------- ----- ---- 22556 06-02-2007 17:57 ReadmeR5.html 4539 04-27-2007 08:09 neol2007.txt 969287 06-03-2007 16:57 2+2gfreq.txt 968736 06-03-2007 16:57 2+2lemma.txt 430196 04-01-2007 15:49 2of12.txt 877489 05-27-2007 18:43 2of12inf.txt 641677 04-01-2007 15:48 5desk.txt 623915 03-02-2003 22:25 2of4brif.txt 37331 01-18-2003 12:01 readme.html 333432 12-01-2002 05:35 6of12.txt 218298 06-18-2002 22:18 3esl.txt 10351 08-19-2000 03:43 agid.txt --------- ------- 5137807 12 files My guess would be that file-roller mis-parses unzip output somehow. I have seen similar behaviour with a 7z archive though, AFAIR. The archive used above can be obtained from: http://downloads.sourceforge.net/project/wordlist/12Dicts/5.0/12dicts-5.0.zip Screenshots in a second.
Created attachment 315099 [details] Demo shot 2/2
It is worth mentioning that this happens only if 7za (provided by p7zip package on Fedora) is available, which gets used for usual zip archives as well. With the p7zip package removed, file-roller resorts to the usual unzip command and everything is back to normal. rpm -q file-roller file-roller-3.16.4-1.fc23.x86_64 rpm -q p7zip p7zip-15.09-4.fc23.x86_64 rpm -q unzip unzip-6.0-24.fc23.x86_64
This issue is limited to the current 15.09 version of p7zip. Dropping a 7za binary built from the source of the 9.38.1 version of p7zip into /usr/local/bin makes the bug disappear. A diff of the output of "7za l <archive_name>" shows that the relevant part with the 15.09 version starts 3 lines later than with 9.38.1.
Created attachment 316844 [details] [review] Bugfix patch With your finding on 9.38.1 versus 15.09 I had a closer look at the source and was able to make a patch to fix the issue, see attachment. I found that file-roller takes a look at the version string produced by p7zip to decide whether it should apply "old style" or "new style" (p7zip >=4.55) parsing. The current version check if (strcmp (version, "4.55") < 0) self->old_style = TRUE; else self->old_style = FALSE; does not handle versions with more than a single digit before the colon properly, which is why "15.09" enables "old style" parsing, which makes else if (self->old_style && (strncmp (line, "Listing archive: ", 17) == 0)) self->list_started = TRUE; start the listing after that line already (i.e. too early), which gets -- Path = /home/user/Desktop/12dicts-5.0.zip Type = zip Physical Size = 1452592 of the p7zip output be parsed and included rather than skipped.
Created attachment 316845 [details] Version check demo, comparing patched and unpatched I'm also attaching a small program to demo the old and new version check in action: # gcc version_check_demo.c && ./a.out OLD OLD 4.0 OLD OLD 4.54 new new 4.55 new new 9.38.1 OLD new 15.09
Thank you very much for your analysis and the patch! What is the reason to keep this check in the current version of file-roller in the first place? Are there any systems in the wild able to run file-roller 3.16 with a version of p7zip that old? Even Debian Squeeze (currently old-old-stable) offers 9.04.
Patch pushed to master and gnome-3-16 branch, thank you.
Paolo, how about a final 3.16 tarball ? There's quite a few bug fixes on that branch after 3.16.4
ok