Bug 838544 - segfault after CTRL+X and CTRL+V in compressed file
segfault after CTRL+X and CTRL+V in compressed file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: file-roller (Show other bugs)
7.0
x86_64 Linux
medium Severity high
: beta
: 7.0
Assigned To: David King
Desktop QE
:
Depends On: 1174580
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-09 08:27 EDT by Martin Simon
Modified: 2016-09-19 22:15 EDT (History)
4 users (show)

See Also:
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 02:22:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Simon 2012-07-09 08:27:10 EDT
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 09:03:16 EDT
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 10:50:14 EDT
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 05:00:38 EDT
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 05:28:25 EDT
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 02:22:00 EST
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

Note You need to log in before you can comment on or make changes to this bug.