D10663: Remove a partially copied file if copyjob was cancelled in the middle of file copying

[David Faure]

dfaure requested changes to this revision.
dfaure added a comment.


  I don't like the idea of a flag for this in the API. It just moves the problem (of whether it's safe / a good idea to clean up) to the applications, who are not in a better place to decide about this. Better make it happen all the time, and better make it work right. A flag almost sounds like a excuse for a half-hearted feature ("if it works badly in case XYZ, then apps can just opt out"). I don't see why the app would care, really. It wants to copy A to B, and wants to know if it worked or not; details like cleaning up on cancel are best handled by the KIO library.
  
  I don't see any provision for the case I mentioned, where the destination file already exists, and should therefore NOT be deleted?
  
  I'm also missing a unittest for this. Now it should be quite easy to unittest. Copy a dir with two files, connect to copyingDone() to know when the first file was copied, then kill the job in the slot [possibly as a Queued invocation]. Dest dir should have only the first file. Then the same when connecting to copying(), i.e. before the copy of the first file. Dest dir should be empty. And then unittests with existing files at destination.
  
  Thanks for your work on this.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10663

To: dmitrio, #frameworks, dfaure
Cc: ngraham, anthonyfieroni, meven, #frameworks, michaelh, kmorwinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180225/0f244bc0/attachment.html>