| Summary: | Cancelling move/copy operation leaves target incomplete | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Charles Phoenix <phoenixreads> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | BryanFRitt, bugseforuns, cippu, kdelibs-bugs, laycastle, mcpatnaik, nate, safa1996alfulaij, tesfabpel |
| Priority: | NOR | Keywords: | usability |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kio/f34c2cf0abf12a96806f9eaac5153dd764ea2215 | Version Fixed In: | 5.57 |
| Sentry Crash Report: | |||
*** Bug 277756 has been marked as a duplicate of this bug. *** 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 *** Bug 320206 has been marked as a duplicate of this bug. *** 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 :) (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... *** Bug 383764 has been marked as a duplicate of this bug. *** *** Bug 290065 has been marked as a duplicate of this bug. *** *** Bug 398337 has been marked as a duplicate of this bug. *** 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 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 *** Bug 148429 has been marked as a duplicate of this bug. *** |
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.