Bug 125102 - Cancelling move/copy operation leaves target incomplete
Summary: Cancelling move/copy operation leaves target incomplete
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
: 148429 277756 290065 320206 383764 398337 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-07 10:05 UTC by Charles Phoenix
Modified: 2021-10-08 14:33 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.57


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Phoenix 2006-04-07 10:05:59 UTC
Version:           3.5.2 (using KDE 3.5.2, Gentoo)
Compiler:          gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
OS:                Linux (i686) release 2.6.15-gentoo-r1

Locally
Move file a large file from pathA to pathB
Cancel before completion

Result
The original is left in pathA
In pathB there is an incomplete copy of foobar.

This causes problems in the following scenario.

1) Copy large number of files from flaky CDROM
2) An error causes the process to be interrupted.
3) {lastfile} is incomplete
4) Copy files again, select overwrite
5) Get stuck doing steps 1-4

6) Alternative choice, select skip existing files
7) Repeat until all files are retrieved
[Yes, I had to do that]

But there are now unknown incomplete files. 


Recommendation (for both copy/move):
copy to foobar.part
rename to foobar only upon completion
if user cancels delete foobar.part

Why this way? Even if the computer crashes the user will know that foobar.part is an incomplete file. What happens if the user looks in target directory see the incomplete foobar, assumes the process was complete, deletes original. Also, if something is referring to foobar it will not be able to reference the incomplete foobar.part.
Comment 1 Christoph Feck 2011-07-15 18:09:43 UTC
*** Bug 277756 has been marked as a duplicate of this bug. ***
Comment 2 Dario 2011-07-17 08:20:03 UTC
I confirm this bug is still present in KDE 4.6.x, i think it is a big usability issue, it's also dangerous because it could lead to data loss
Comment 3 Dawit Alemayehu 2013-09-10 05:52:25 UTC
*** Bug 320206 has been marked as a duplicate of this bug. ***
Comment 4 tesfabpel 2016-08-10 16:15:28 UTC
This bug is still present on Dolphin 5.24.0 with frameworks 5.7.0 running on Archlinux 64bit...

Any news on this? It's very dangerous!
Thanks :)
Comment 5 tesfabpel 2016-08-10 16:16:54 UTC
(In reply to tesfabpel from comment #4)
> This bug is still present on Dolphin 5.24.0 with frameworks 5.7.0 running on
> Archlinux 64bit...
> 
> Any news on this? It's very dangerous!
> Thanks :)

Sorry... Dolphin 16.04.3 with frameworks 5.24.0 and Qt 5.7.0...
Comment 6 Nate Graham 2018-04-17 22:10:36 UTC
*** Bug 383764 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2018-04-24 20:43:24 UTC
*** Bug 290065 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2018-09-07 14:06:00 UTC
*** Bug 398337 has been marked as a duplicate of this bug. ***
Comment 9 Chinmoy Ranjan Pradhan 2019-03-03 08:56:34 UTC
Git commit f34c2cf0abf12a96806f9eaac5153dd764ea2215 by Chinmoy Ranjan Pradhan.
Committed on 03/03/2019 at 08:56.
Pushed by chinmoyr into branch 'master'.

Make file overwrite a bit safer

Summary:
Instead of truncating the existing file, a separate copy of the source file in the
destination folder is created. If the copy was successfully created, the existing
destination file is replaced with it. If in middle of creating the separate copy the
disk runs out of space then an attempt is made to delete the existing destination.
After that is done the copy operation is resumed.
FIXED-IN: 5.56

Test Plan: Unit testing and manual testing done.

Reviewers: dfaure, ngraham

Reviewed By: dfaure, ngraham

Subscribers: kde-frameworks-devel

Tags: #frameworks

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

M  +47   -0    autotests/jobtest.cpp
M  +2    -0    autotests/jobtest.h
M  +42   -16   src/ioslaves/file/file_unix.cpp

https://commits.kde.org/kio/f34c2cf0abf12a96806f9eaac5153dd764ea2215
Comment 10 Ralf Habacker 2019-04-27 01:26:44 UTC
Git commit 04580cac31b1f1a1491a1fc54cfc4c724ce50cd9 by Ralf Habacker.
Committed on 27/04/2019 at 01:26.
Pushed by habacker into branch 'Applications/19.04'.

file import: do not use overwritten temporary file

We checked if the temporary file we created still exists after its creation,
yet in the meantime we have already copied to it (which overwrites it):
KIO::FileCopyJob *job = KIO::file_copy(url, dest, -1, KIO::Overwrite);

Instead of the temporary file, check if the regular file we use later on
exists.

This bug is a result of fixing bug 125102.
Related: bug 406574
FIXED-IN:2.28.0 (KDE Applications 19.04.0)

Reviewed By: habacker
Differential Revision: https://phabricator.kde.org/D20775

M  +4    -4    umbrello/umldoc.cpp

https://commits.kde.org/umbrello/04580cac31b1f1a1491a1fc54cfc4c724ce50cd9
Comment 11 Méven Car 2021-10-08 14:33:19 UTC
*** Bug 148429 has been marked as a duplicate of this bug. ***