Bug 398337

Summary:	Trying to overwrite a file with a corrupted file deletes the former
Product:	[Applications] dolphin	Reporter:	Safa Alfulaij <safa1996alfulaij>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	major	CC:	andrew.crouthamel, elvis.angelaccio, nate
Priority:	NOR
Version First Reported In:	18.08.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Safa Alfulaij 2018-09-06 20:00:50 UTC

I was trying to copy-past several files from my fat32 USB stick. One file had a problem and Dolhpin told me (by a dialog) that it can't be copied. Do you want to skip or skip all etc. etc.
I chose Skip and then found that I don't that file in the destination location. I tried copying it again from the USB stick and it was the same. I took the stick to Windows and it refused to copy/open it asking to check the stick for errors. I've done that and the file was gone too. (The file was really corrupted)

The issue here is that Dolphin should make sure 100% that the destination file is not corrupted before deleting the current file, or to just keep it as backup if anything goes wrong.

Now I have to rewrite that ~300-lines main tex file again :)

Comment 1 Andrew Crouthamel 2018-09-07 05:29:35 UTC

If you were using copy + paste, the source file is untouched. I would not attribute the loss of the file from CHKDSK on Windows, to Dolphin.

Comment 2 Safa Alfulaij 2018-09-07 05:43:34 UTC

(In reply to Andrew Crouthamel from comment #1)
> If you were using copy + paste, the source file is untouched. I would not
> attribute the loss of the file from CHKDSK on Windows, to Dolphin.

The idea is that I'm overwriting the original file, with a corrupted file. At the end of the copy process, the original file is deleted and the corrupted (new) file couldn't be copied. I will try again and check to see if the source file is really untouched in this case.

Comment 3 Nate Graham 2018-09-07 14:06:00 UTC

> At the end of the copy process, the original file is deleted and the
> corrupted (new) file couldn't be copied

I think this has the same root cause and fix as 125102. A fellow tried to submit a patch to fix that with https://phabricator.kde.org/D10663, but it didn't end up working out. Would you like to try your hand at it, Safa? You seem like a pretty capable fellow. :)

*** This bug has been marked as a duplicate of bug 125102 ***