Bug 355493 - Gwenview Caused Severe Data Loss When Performing Delete File Operation
Summary: Gwenview Caused Severe Data Loss When Performing Delete File Operation
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: Other (add details in bug description)
Platform: openSUSE Linux
: NOR critical
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
: 363849 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-17 14:16 UTC by boblovgren55
Modified: 2017-11-09 14:53 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description boblovgren55 2015-11-17 14:16:21 UTC
gwenview (15.08.2)
openSUSE Tumbleweed (20151115) (x86_64)
KDE Plasma Version 5.4.2
Qt Version: 5.5.1
Linux Kernel: 4.3

Last night I was using gwenview 15.08.2 and had an image loaded which was minimized to the task manager. I used the "Delete" file operation option found on the sidebar. The problem was that I forgot I deleted this particular image in dolphin antecedent to pressing the delete button on gwenview's sidebar. In other words, the image that I was attempting to delete using gwenview's file operations had already been deleted yet was still loaded in memory.

Instantly I heard hard drive activity and wondered what was going on. I received a delete file dialogue which showed files being deleted out a random +100 GB folder I have in /home. I stopped it as fast as possible, and after checking the folder I noticed around 1000 files were missing. Luckily I had a backup, but now I am hesitant to use the Delete file operation after this fiasco. I have no idea why gwenview picked this particular folder to erase over other multi-gigabyte folders in my /home directory.

I will try to reproduce this on another test machine today, but in the meantime I would really appreciate a serious look into this issue.

Reproducible: Didn't try

Steps to Reproduce:
1. Load image into gwenview
2. Delete file with Dolphin
3. User gwenview's delete file operation on sidebar
Comment 1 xunilhcra 2016-06-27 23:38:39 UTC
I can confirm this bug, also please see: https://bugs.kde.org/show_bug.cgi?id=363849
Comment 2 Nate Graham 2017-09-10 04:14:36 UTC
*** Bug 363849 has been marked as a duplicate of this bug. ***
Comment 3 Nate Graham 2017-09-10 04:14:50 UTC
Wow, this is really bad.
Comment 4 Valerii Malov 2017-10-06 21:37:12 UTC
This could be probably fixed by resetting the mViewMainPage and switching back to "Browse" tab when Gwenview tries to open an invalid selection

However, Gwenview also opens remote files, and does that in a manner that interferes with normal operation, so resetting the view breaks it

Here's a couple of interesting exercises:

First
- Open thumbnail view, select some folder or file
- Open remote file (e.g. via http)
- Tap "Delete"
- Selected files or folders are now gone

Second
- Open a local file via thumbnail view
- Open remote URL
- Click on the "Browse" button on the toolbar
- Click on the local file you had opened before
- You still have the remote image opened in the View tab
Comment 5 Nate Graham 2017-10-06 21:41:09 UTC
Please feel free to post a patch for review at https://phabricator.kde.org/. Even if it's imperfect, you may get some good ideas and suggestions for improvement.
Comment 6 Valerii Malov 2017-11-09 14:53:24 UTC
Git commit b55420b2ac3dc72ebffdb89dbb9e662d64950ecd by Valeriy Malov.
Committed on 09/11/2017 at 14:52.
Pushed by valeriymalov into branch 'master'.

Try to keep ContextManager in sync with viewed files in MainWindow

Summary:
ContextManager now is responsible for switching to the directory
containing requested URL and selecting it. However, if it is not
possible, URL is still kept (in case of remote URLs), while selection is
cleared (to avoid dragging in local files)

MainWindow now relies on ContextManager's selection and/or
selectedFileItemList instead of ThumbnailView selection. If selection &
currentUrl are empty, refuse to open View tab, otherwise display
selected items.

This should prevent (reduce?) the amount of mismatches between which
files user sees, and which files are being operated upon
(e.g. by FileOpsContextManagerItem)
Related: bug 275807, bug 326190, bug 306835

Test Plan:
Tried playing around to make sure it doesn't break any old behaviour
Tried deleting all image files while in View mode, to make sure we back out when we run out of images
Tried opening an http url and check that operations apply to it unless we select something in browse tab
And then remote image should be unloaded from the View tab since our actions will now affect user-selected items

Tests pass but they don't seem to cover this?

Reviewers: #kde_applications, gateau, rkflx

Reviewed By: gateau, rkflx

Subscribers: ngraham, rkflx, gateau

Differential Revision: https://phabricator.kde.org/D8196

M  +1    -11   app/fileopscontextmanageritem.cpp
M  +27   -70   app/mainwindow.cpp
M  +25   -2    lib/contextmanager.cpp
M  +1    -0    lib/contextmanager.h

https://commits.kde.org/gwenview/b55420b2ac3dc72ebffdb89dbb9e662d64950ecd