dmitrio abandoned this revision. dmitrio added a comment.
In D10663#213898 <https://phabricator.kde.org/D10663#213898>, @dfaure wrote: > I don't see any provision for the case I mentioned, where the destination file already exists, and should therefore NOT be deleted? In fact, this is exactly the case that I tried to deal with here. In this proposal the destination file gets deleted only if some data has been written into it, so all the previous data are already lost regardless of our cleanup. What is not handled here is the case of moving to another partition, where subjob may launch original file deletion just after successful file copying and before emitting result, which may lead to cleanup being done when the original file can potentially be deleted. I also expect some trouble with job pause feature when user may pause this job, eventually start copying the same file with another tool (be it something like `cp` or another instance of CopyJob), and then abort this job. For this case we should probably add something like a check on whether size×tamp of the destination file has changed since our last change of that file. So it seems that to work properly this feature needs some more complex solution including, probably, some separate job class dealing with cleanup and all the necessary safety checks. For now, I can only apologize for underestimating the problem and rolling out such a raw solution for it. I am probably better to close it, if I am able to come up with better solution I will reopen this request (if it is possible) or open a new one. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D10663 To: dmitrio, #frameworks, dfaure Cc: ngraham, anthonyfieroni, meven, #frameworks, michaelh
