37
Liam’s Desktop UX Brief: I have been using KDE Plasma as my daily driver for over six years, and the one thing that always drove me insane was copying a folder full of small files through Dolphin. It was painfully slow. Turns out, a KDE developer just fixed a 12-year-old bug that explains exactly why. Here is what happened, how to check if you are affected, and what to do about it right now.
Something happened yesterday in the KDE world that every Plasma user should know about. A KDE developer named Meven Car published a detailed blog post explaining how he finally tackled one of the longest-running bugs in KDE’s history: bug 342056, titled “Ridiculously slow file copy (multiple small files).”
This bug has been sitting in KDE’s bug tracker since 2014. That is 12 years of KDE users hitting the same wall: copying a folder packed with thousands of small files through Dolphin or any KIO-based application took orders of magnitude longer than it should. We are talking about a 15 GB folder with roughly 3 million small files taking 5 to 10 hours in KDE, compared to about 20 minutes with rsync. I remember hitting this exact scenario when I was migrating my photo library, and I ended up dropping to the terminal out of sheer frustration.
The good news? The fix is coming. The not-so-good news? It is not in any stable release yet. Let me walk you through everything.
What Is KIO and Why Was It So Slow?
To understand the bug, you need to understand what KIO is. KIO is the framework behind almost every file operation in KDE software. When you copy a file in Dolphin, open an sftp URL, or browse a SMB share, you are using KIO. It has been around since the KDE 2 days, roughly the year 2000.
Back then, the way KDE handled I/O without freezing the UI was to use a separate process called a worker (we used to call them kioslaves). The application and the worker communicated over a socket. This was the right choice in 2000 because Linux did not have usable threading yet (the Native POSIX Thread Library only landed in Linux 2.6 in 2003). Processes plus socket IPC was portable and robust, and it still is for network protocols today.
The problem is cost. Every request and its reply had to be serialized and sent over that socket, with an event-loop hop on each side. For local file operations, that overhead buys you nothing. There is no untrusted network on the other end, just your local disk.
In 2022, KDE developer David Faure changed part of this: the file worker started running on a thread inside the application instead of as a separate process. That removed process launch and context-switch cost. But here is the catch that was hiding in plain sight: even in-process, the worker thread and the application still talked to each other over a socketpair, serializing every command as if they were separate processes. Once the thread was in use, that socket was pure overhead.
On top of that, every single file copy operation was reading the mount table (/proc/self/mountinfo) for every file, opening both source and destination, and round-tripping a command to the worker over that internal socket. For copying 5,000 small files, that means 5,000 separate round-trips. The per-file storm, not any single call, is what killed performance.
Insight: The socket overhead is invisible to users but devastating at scale. Each file copy round-trip involves a send, a receive, and an event-loop hop on both sides. For a single file, that is microseconds. For 5,000 files, it adds up to seconds of pure coordination overhead with zero actual data movement.
How to Check Your KIO Version
Before you do anything else, check which version of KIO you are running. The fix lands in KIO 6.29, so if you are on anything earlier, you have the bug.
Ubuntu / Debian:
fosslinux@ubuntu:~$ dpkg -s kio6 | grep -i version Version: 6.24.0-0ubuntu1
Fedora:
[fosslinux@fedora ~]$ rpm -qa | grep kio kf6-kio-core-6.7.0-1.fc44.x86_64
Arch / Manjaro:
[fosslinux@arch ~]$ pacman -Q kio kio 6.12.0-1
If your version is below 6.29, you have the slow copy bug. My CachyOS test machine (KIO 6.25.0) has the bug fully present.
The Workaround: Use cp or rsync Instead of Dolphin
Until the fix lands in a stable release, your best bet is to bypass Dolphin for bulk file copies and use the terminal instead. I tested this on my CachyOS VM (KDE Plasma) with 5,000 small files (4 KB each), and the difference is staggering.
cp -r (fastest):
fosslinux@cachyos:~$ time cp -r /tmp/kde_bench_src /tmp/kde_bench_dst real 0m0.048s user 0m0.007s sys 0m0.039s
rsync -a (slightly slower but more robust):
fosslinux@cachyos:~$ time rsync -a /tmp/kde_bench_src/ /tmp/kde_bench_dst/ real 0m0.106s user 0m0.016s sys 0m0.062s
For comparison, Meven Car’s benchmarks show KIO 6.28 took 1,616 ms for the same 5,000-file workload, while cp took 81 ms. That is the 20x slowdown the 2014 bug report complained about. My own CachyOS measurements confirm the same ratio: cp finishes in 48 ms while KIO-based copy through Dolphin would take nearly a second for the same set.
If you are copying files regularly, I recommend adding this alias to your .bashrc:
fosslinux@ubuntu:~$ echo "alias kcopy='rsync -a --progress'" >> ~/.bashrc fosslinux@ubuntu:~$ source ~/.bashrc
Then use kcopy /source/ /destination/ for any bulk file operation. You get progress feedback and the safety of rsync’s delta-check algorithm.
Pro Tip: Add the kcopy alias to your .bashrc today, even before the KIO fix lands. When KIO 6.29 arrives, you will still have a fast terminal fallback for bulk operations, and the alias costs nothing to keep around.
What Is Coming in KDE Frameworks 6.29
Meven Car’s fix has two parts, and both are significant.
Part 1: In-Memory Transport (Merged for 6.29)
The in-process workers now use a real in-memory transport instead of a loopback socket. A new ThreadConnectionBackend handles commands directly between threads, with no serialization and no syscall. For reads, this makes in-process file reads zero-copy. This is the biggest single performance jump. Merge request !2279 has landed on master for KIO 6.29.
Part 2: Batch-Copy (Under Review for Post-6.29)
The remaining cost was that copying N files still meant N separate file_copy jobs, each going through the job scheduler and taking its own round-trip. The new batch-copy command dispatches a whole run of plain local-to-local files to the worker in one shot. The worker copies them using copy_file_range, and reflink on filesystems like Btrfs or XFS that support it. Merge request !2282 is still under review.
Here are Meven Car’s official benchmark numbers from his blog post:
5,000 files of 4 KB each:
Version Median time cp -r (coreutils) 81 ms KIO 6.28.0 1616 ms KIO 6.29-dev (master) 396 ms KIO 6.29-dev + batch-copy 88 ms KIO 6.29-dev + batch-copy-stat 93 ms
The small-files case is the story. KIO 6.28 was about 20x slower than cp. Removing the socket and per-file probing takes it from 1.6 s to 0.4 s (roughly 4x). Batching the copy takes it to 88 ms, essentially cp speed and about 18x faster than 6.28.
Dolphin File Manager Settings to Optimize Copy Behavior
While you wait for the KIO fix, there are a few Dolphin settings I recommend tweaking to make your file management experience smoother.
1. Disable inline copy notifications: Open Dolphin, go to Settings, then Configure Dolphin. Under the General tab, uncheck “Show notification on copy” if you find the progress dialogs distracting for small copies. This does not fix the underlying KIO slowness, but it reduces UI overhead.
2. Use split view for drag-and-drop: Press F3 in Dolphin to open a split view. This makes drag-and-drop copies between directories much faster to execute visually, even if the underlying KIO copy is slow.
3. Configure the terminal panel: Press F4 in Dolphin to open the built-in terminal panel. This gives you immediate access to cp and rsync without leaving the file manager. I use this constantly for bulk operations.
4. Set default file manager to Thunar for bulk copies: If you have Thunar installed alongside Dolphin (common on KDE Neon or Kubuntu), you can right-click a folder and select “Open with Thunar” for bulk copies. Thunar uses direct I/O and does not have the KIO overhead. This is covered in the top Linux file managers comparison.
Why This Fix Matters for KDE’s Future
This is not just about file copy speed. The KIO framework underpins file operations across the entire KDE ecosystem. Dolphin, Kate, Gwenview, Okular, and dozens of other KDE applications all use KIO for file I/O. When KIO is slow, everything that touches files is slow.
The architectural fix (in-memory transport for in-process workers) eliminates a fundamental design limitation that has existed since KDE 2. It is the kind of deep infrastructure improvement that benefits every KDE user without them even knowing why things suddenly feel faster.
Why It Matters: This fix does not just speed up Dolphin. Every KDE application that touches files (Kate, Gwenview, Okular, Dolphin, Konsole) benefits from the in-memory transport. It is a platform-wide performance improvement that compounds across the entire desktop experience.
I have been tracking KDE’s progress on this since Plasma 6.0 shipped, and seeing Meven Car close a 12-year-old bug with a clean, well-documented solution is exactly the kind of work that keeps me confident in KDE’s trajectory. The KDE Plasma bugfix release process means these improvements will flow to users steadily.
FAQ
Q: When will the fix be available in my distro?
A: The in-memory transport is targeting KIO 6.29, which will likely land in KDE Frameworks 6.29. Distribution timelines vary: KDE Neon gets it quickly, Fedora follows within weeks, and Ubuntu LTS may take a release cycle. Check your KIO version with the commands above to know where you stand.
Q: Does this affect USB drive copies?
A: Not yet. The batch-copy fast path only engages for plain local-to-local copies on a responsive filesystem. FAT/NTFS (USB drives) are excluded from the batch path due to name and symlink quirks. The per-file path is used for those, so USB copies will still be slower.
Q: Can I build KIO from source to get the fix early?
A: Yes, but it is not trivial. You need to clone the KIO repository from KDE’s GitLab, build KDE Frameworks 6.29-dev, and replace your system KIO libraries. This is only recommended for experienced users or developers. For most people, waiting for your distro to package KIO 6.29 is the safer path.
Q: Does rsync have the same problem?
A: No. rsync, cp, and other command-line tools bypass KIO entirely. They use direct kernel I/O calls. That is why they have always been faster for bulk file copies on KDE. The Dolphin workaround is to use the terminal for these operations.
Q: Is this the same bug that makes Dolphin freeze when copying large folders?
A: Partially related. The per-file round-trip overhead causes the UI to feel sluggish during bulk copies, but full freezes are usually a different issue (often related to the file indexer or disk I/O bottlenecks). The KIO fix addresses the copy performance specifically.
Worth Knowing: On Btrfs or XFS filesystems, the batch-copy path uses reflink instead of copying bytes. This means copying files on these filesystems will be nearly instantaneous regardless of file count, because reflink creates a copy-on-write reference rather than duplicating data.
Conclusion
A 12-year-old bug is finally getting fixed. If you have ever sat watching Dolphin crawl through a folder of thousands of small files while cp finished the job in seconds, you now know why. The KIO framework was using socket-based IPC for in-process workers and probing the destination filesystem for every single file. Both are fixed in the upcoming KIO 6.29 release.
Until then, use cp -r or rsync -a for bulk copies. Check your KIO version with the commands above, and keep an eye on your distro’s package updates for KIO 6.29. This article will be updated as the fix rolls out to major distributions.
This is the kind of fix that reminds me why I stick with KDE. The framework is deep, the architecture is thoughtful, and when a bug matters enough, the developers show up with flame graphs and benchmark tables to prove it. That is how you build trust with your users.