Bug 838544

Summary: segfault after CTRL+X and CTRL+V in compressed file
Product: Red Hat Enterprise Linux 7 Reporter: Martin Simon <msimon>
Component: file-rollerAssignee: David King <dking>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0CC: mclasen, tpelka, vbenes, vhumpa
Target Milestone: beta   
Target Release: 7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: file-roller-3.14.2-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 07:22:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1174580    
Bug Blocks:    

Description Martin Simon 2012-07-09 12:27:10 UTC
Description of problem:
If i have compressed file by file-roller, e.g. file.gz (it's only one file named 'file' compressed by gzip), I can open it in file-roller (it looks like an archive) and when I select the file in it, press CTRL+X (cut) and CTRL+V (paste), the dialog asking for name where to paste appeared, but it shouldn't. If i wrote any name and confirm, file-roller ends with segfault.

Version-Release number of selected component (if applicable):
file-roller-3.4.2-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. open any file compressed with with gzip or bzip2 (only compressed, not an archive)
2. select the file, press CTRL+X and CTRL+V
3. enter the name of folder and confirm
  
Actual results:
segfault

Expected results:
The dialog asking for the place where to save should not appear. The menu buttons in Edit menu are grayed and unreachable, so the dialog should not appear after shortcut neither.

Additional info:

Comment 3 David King 2014-03-20 13:03:16 UTC
In file-roller-3.8.3-3.el7.x86_64 the segfault no longer occurs, but the behaviour is still incorrect, in that the dialog is shown. The upstream fix for the incorrect bahaviour was committed only recently, in 3.11.4, and looks rather invasive to backport:

https://git.gnome.org/browse/file-roller/commit/?id=58f52e2bc88a79bb4be6691c12b8c4f71decf78e

As there is no longer a crash, I think any fix should be postponed to 7.1.0.

Comment 6 Vitezslav Humpa 2015-07-13 14:50:14 UTC
The crash is not present anymore, however the dialog/file removal issue is still present in 3.14.

That is: cutting and pasting the file in the same location leads into the file being deleted. First the file is copied onto itself, and since we're performing a cut action, the source file (in this case the same file) is deleted afterwards. With i.e. a similar action in nautilus, file is merely copied over itself, not removed afterwards.

Comment 7 David King 2015-07-15 09:00:38 UTC
I cannot reproduce the behaviour, with a single gzipped file (just running "gzip file", and opening the resulting "file.gz" in file-roller). The cut, copy and paste actions are disabled, so the bug cannot be triggered.

The linked testcase does not take this information (about the single-file archive, from comment #0) into consideration, and is for the more generic multi-file archive case. That seems like a genuine bug, but the file-roller rebase completely fixed the initial report. I do not know whether it is better to fix the test case or add a new one, but it seems like a new bug is needed for the multi-file archive copy/psate behaviour.

Comment 8 Martin Simon 2015-07-15 09:28:25 UTC
I agree, the bug was reported as the crash occurred, which is obviously fixed by the rebase (all the options are disabled, no crash). The linked test case covers a different bug, which I reported as a bug 1243347

Comment 10 errata-xmlrpc 2015-11-19 07:22:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2215.html