<table><tr><td style="">dfaure requested changes to this revision.<br />dfaure added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D10663" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>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.</p>

<p>I don't see any provision for the case I mentioned, where the destination file already exists, and should therefore NOT be deleted?</p>

<p>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.</p>

<p>Thanks for your work on this.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D10663" rel="noreferrer">https://phabricator.kde.org/D10663</a></div></div><br /><div><strong>To: </strong>dmitrio, Frameworks, dfaure<br /><strong>Cc: </strong>ngraham, anthonyfieroni, meven, Frameworks, michaelh, kmorwinski<br /></div>