<table><tr><td style="">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/D10702">View Revision</a></tr></table><br /><div><div><p>s/thread/process/. It's not about threads it's about two processes: the (GUI) application, and the kioslave.</p>

<p>But you present all this in a rather convoluted way, it's much simpler. The SimpleJob for asking a kioslave to delete a file is KIO::file_delete which exactly what this patch ends up calling.</p>

<p>The issue is choosing when to call unlink directly and when to ask the slave to do it. Or indeed markg's idea of sending the full list of files to the slave in one go, with a new MultiDeleteJob (including progress information). However for many small files this might be slower (that long list needs to be sent over...).</p>

<p>Since the bug report is about the "one big file" case, I'd say let's not fix what ain't broken (the many small files case), and let's just do "if local and small, delete in-process, otherwise use kioslave", i.e. just adding a size check for the fast path.</p>

<p>The optimized way to do it would be, rather than a stat() in this method, to change DeleteJobPrivate::slotEntries so that it puts big files into a separate list, for instance.</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">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, bruns<br /></div>