Red Hat Bugzilla – Bug 838544
segfault after CTRL+X and CTRL+V in compressed file
Last modified: 2016-09-19 22:15:21 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):
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
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.
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:
As there is no longer a crash, I think any fix should be postponed to 7.1.0.
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.
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.
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
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.