Version: 4.7.3 (using KDE 4.7.3) OS: Linux Canceling a Copy* [or having a copy interrupted] leaves incomplete file, instead of deleting the incomplete file, or even asking the user if they want to keep the incomplete file. There's no way to distinguish between a completed copy and the incomplete copy just by looking at the file name. *haven't test move, move across partitions, etc... as of typing this p.s. Should I put the Severity as Major or Normal? Since it's a bug that could cause data loss depending upon user actions? (like they think the didn't hit the cancel button in time, and think they have a complete copy, even though they don't, etc..., or they try copying files again, choosing the skip existing files option, not realizing there's a partial file that'll be skipped in there.) Reproducible: Always Steps to Reproduce: Try to copy a file, and either click cancel, or disconnect the drive, terminate Konqueror, etc... before the file is finished. Actual Results: The file will still be incomplete, and still there, and no error message. Expected Results: The incomplete file is deleted, or at least ask the user if they want to keep the incomplete file. Maybe even a stop after this file option, if copying more than one file. There could be a way to distinguish a partway done file instead a complete one. like making the temp file name something like .IncompleteCopy.OriginalFileName.Ext.IncompleteCopy~ .IncompleteMove.OrginalFileName.Ext.IncompleteMove~ Then renaming it to OriginalFileName.Ext when it's completely copied/moved. OS: Linux (x86_64) release 3.0.0-14-generic Compiler: gcc
A count like ~001, ~002, ~003, or a date-time stamp `date +"%F_%H:%M:%S.%N"`, etc ... could be added to the temp filename to minimize collision effects with existing filenames of incomplete copies. (for in situations when asking will more copy this time around than last?, like when dealing with a bad hard drive?). Although this could just leave to having multiple incomplete copies that aren't of much use. User choice in config, or just do it?
I'd say this is neither a major severity nor is it a bug. I'd say this shall be marked as a wish. What you see is normal behavior even when you "cp" a file on the commandline. Or think about copying a file to an USB stick but you forget to unmount the stick before you pull it. In the latter case there is nothing KDE could do as the OS will flush its internal buffers at some point in time or when you unmount at the latest Note however that konqueror names partly downloaded files e.g. from http or ftp like FileName.part until it completed the download and then renames it to FileName. This could be done also for local filesystems (however you still would have the problem with the unflushed buffers. Even the sync(2) manpage says: "According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)"
There could at least be a popup message/log file saying something like, file transfer of __A.From__ to __A.Dest___ didn't complete, there may be an incomplete file at what was __A.Dest__.
*** This bug has been marked as a duplicate of bug 125102 ***