Bug 290065

Summary:	Canceling a Copy leaves incomplete file...
Product:	[Unmaintained] kio	Reporter:	BryanFRitt <BryanFRitt>
Component:	general	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED DUPLICATE
Severity:	wishlist	CC:	BryanFRitt, kollix, nate
Priority:	NOR
Version:	4.7
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description BryanFRitt 2011-12-29 04:04:21 UTC

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

Comment 1 BryanFRitt 2011-12-29 04:36:53 UTC

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?

Comment 2 Martin Koller 2012-01-05 19:08:01 UTC

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.)"

Comment 3 BryanFRitt 2014-10-01 00:11:02 UTC

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__.

Comment 4 Nate Graham 2018-04-24 20:43:24 UTC


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