Deleting a ZIM file should move it to the trash can

[Ubuntu-2020]

When I delete a ZIM file from the library, it is also deleted from the hard disk at the same time! And the basket remains empty!
Ubuntu 18.04 Unity + Kiwix 2.0.1-1 (*.appimage):

The situation is exactly the same in the operating system Ubuntu 18.04 MATE + Kiwix 2.0.1-1 (*.appimage).

[kelson42]

Honestly, I'm not convinced we should implement that.

[mgautierfr]

We should not delete the zim file if it was not downloaded by kiwix-desktop itself (if we add it to the library because the user open a existing zim).

[kelson42]

Interesting Qt ticket https://bugreports.qt.io/browse/QTBUG-47703

[aweasadbek]

Yesterday, I wanted to remove full wikipedia from kiwix-desktop library. I left clicked on wikipedia and clicked delete - I thought that this would remove wikipedia from kiwix-desktop, but I lost my dump file. I spend about a month to download my dump.
Why there's not even a warning that it would delete file from disk. It could lead to a big problems in a remote schools. If someone repeats my mistake the whole school would be in trouble.
Please at least add warning that the file is going to be deleted! If possible make it impossible to delete file from disk using kiwix.
Please try to understand. Humans always make mistakes.

[aweasadbek]

Moving to trash will not work. Cause the installation partition won't be big enough to contain large dumps. The system will fail and large dump will not be moved to trash. So person who is comfortable that file would be moved to trash, will be really upset after knowing that it's deleted.
Remote schools could be using low end computer with low memory and dump file in a separate disk.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[kelson42]

I believe that we shoudl move the ZIM file to the trash instead of just deleting it from the fs. This should at least be the configuration per default. A message at delete time should clearly tell the user that the ZIM is in the trashbox.

A settings (deactivated per default) could be done to allow to shortcut trash and immediatly delete "for ever" the file.

@juuz0 I wonder a bit of what will happen if a ZIM downloaded in the internal library via Kiwix is then restored from the trashbox. Then it won't reappear in the Kiwix library... and the user might be quite puzzle to know what to do? Do you agree? Do you have an idea to deal with that?

[kelson42]

@juuz0 Any feedback?

[juuz0]

I believe that we shoudl move the ZIM file to the trash instead of just deleting it from the fs. This should at least be the configuration per default.

✅

A settings (deactivated per default) could be done to allow to shortcut trash and immediatly delete "for ever" the file.

✅

A message at delete time should clearly tell the user that the ZIM is in the trashbox.

✅

I wonder a bit of what will happen if a ZIM downloaded in the internal library via Kiwix is then restored from the trashbox.

I put the download directory into monitoring (same function as monitor directory) - so if the file is downloaded from kiwix downloader followed by moving it to trash can, if the user restores the file - it appears in Kiwix library too. Test and let me know how it works!

[kelson42]

@juuz0 perfect on the principle. I though we have still a bug relazed to monitoring!? Was not sure at all it would be a good idea to alwaya monitor the download directory.

With this PR, would you be able to tacle #517 as well?

[juuz0]

I though we have still a bug relazed to monitoring!

It was in the back of my mind that there was a bug but I can't reproduce it using the new library code.

With this PR, would you be able to tacle #517 as well?

I don't think so. I wrote a comment there about a possible way to handle just now.