<table><tr><td style="">jtamate requested changes to this revision.<br />jtamate added a comment.<br />This revision now requires changes to proceed.
</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/D10702" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>My guess is that the problem is not in the direct delete of local files.<br />
In fact, unlink() in most of the modern filesystems is not affected by the size of the file and is quite fast.</p>

<p>Another way to reproduce this bug:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Create a directory</li>
<li class="remarkup-list-item">Create 50.000 files of 2 bytes each one, for example with: "for i in <tt style="background: #ebebeb; font-size: 13px;">seq -w 1 50000</tt>; do dd if=/dev/urandom of=file-$i.go bs=1 count=2; done"</li>
<li class="remarkup-list-item">Go to that directory, select all files and shift-supr them.</li>
<li class="remarkup-list-item">Confirm the dialog with the list of files to delete.</li>
</ul>

<p>Wait too much for the task to start.<br />
And after the notification of the work done, wait again for dolphin to become responsive.</p>

<p>The same problem affects the rename task in such directory,</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/D10702" rel="noreferrer">https://phabricator.kde.org/D10702</a></div></div><br /><div><strong>To: </strong>meven, Frameworks, dfaure, ngraham, Dolphin, jtamate<br /><strong>Cc: </strong>jtamate, markg, ngraham, Frameworks, michaelh<br /></div>