Step to reproduce 1. Select a 1 Go file (or any file that you take more than 1 second to delete on your drive) 2. Hit shift-del 3. confirm. Actual Result: Dolphin UI hangs until the file is deleted. The confirmation window can stay open while the UI is frozen. Expected Result: Dolphin UI is responsive. I believe the bug is in fact in KIO::DeleteJob around lines : // Normal deletion // If local file, try do it directly if ((*it).isLocalFile() && QFile::remove((*it).toLocalFile())) { qDebug() << "DeleteJobPrivate::deleteNextFile isLocalFile" << QDateTime::currentDateTime(); job = nullptr; m_processedFiles++; if (m_processedFiles % 300 == 1 || m_totalFilesDirs < 300) { // update progress info every 300 files m_currentURL = *it; slotReport(); } } else { // if remote - or if unlink() failed (we'll use the job's error handling in that case) // qDebug() << "calling file_delete on" << *it; if (isHttpProtocol(it->scheme())) { job = KIO::http_delete(*it, KIO::HideProgressInfo); } else { job = KIO::file_delete(*it, KIO::HideProgressInfo); job->setParentJob(q); } Scheduler::setJobPriority(job, 1); m_currentURL = (*it); } It makes deletion synchronous by default for any local file. Any slow device or big files will cause the UI to freeze. A workaround I have tested with success is removing the localFile fast-path: // Normal deletion // If local file, try do it directly if ((*it).isLocalFile() && QFile::remove((*it).toLocalFile())) { qDebug() << "DeleteJobPrivate::deleteNextFile isLocalFile" << QDateTime::currentDateTime(); job = nullptr; m_processedFiles++; if (m_processedFiles % 300 == 1 || m_totalFilesDirs < 300) { // update progress info every 300 files m_currentURL = *it; slotReport(); } } else { It could be nice to mark the files in the UI as gray or give a some feedback that the file is being deleted. Could be related to: https://bugs.kde.org/show_bug.cgi?id=389807 https://bugs.kde.org/show_bug.cgi?id=382779 https://bugs.kde.org/show_bug.cgi?id=380250
Thanks for the high-quality bug report! Would you be interested in producing a patch for this issue?
I am indeed. I will start tomorrow probably. My workaround could be a start, but I need to do some tests to avoid regression and keep a good user experience. It might require some UI work in dolphin to make it clear that a file is being deleted. Otherwise If a user removes a big file, he will only notice that it worked when the deletion completes and the file disappear in the UI.
Re-assigning KIO where deletejob lives
Seems related to https://bugs.kde.org/show_bug.cgi?id=358231 I know from seeing the code that copying has the same issue as deletion : it is synchronous. I guess moving files is also affected. It uses DirectCopyJob for local files which will hang the app for as long as the copy is going on.
I've just opened this bug which might be related : https://bugs.kde.org/show_bug.cgi?id=400025
Related to https://bugs.kde.org/show_bug.cgi?id=358231
Git commit 80d5f52b0675912b1522209746357c41742fe611 by Méven Car. Committed on 14/11/2019 at 08:35. Pushed by meven into branch 'master'. [DeleteJob] Use a separate worker thread to run actual IO operation Summary: FIXED-IN: 5.65 Reviewers: dfaure, #frameworks Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Maniphest Tasks: T11627 Differential Revision: https://phabricator.kde.org/D24962 M +176 -72 src/core/deletejob.cpp https://commits.kde.org/kio/80d5f52b0675912b1522209746357c41742fe611