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
