<table><tr><td style="">dmitrio abandoned this revision.<br />dmitrio 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><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D10663#213898" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: line-through;" rel="noreferrer">D10663#213898</a>, <a href="https://phabricator.kde.org/p/dfaure/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@dfaure</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><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></div>
</blockquote>

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

<p>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 <tt style="background: #ebebeb; font-size: 13px;">cp</tt> or another instance of CopyJob), and then abort this job. For this case we should probably add something like a check on whether size&timestamp 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.</p>

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