Yes, the files really are deleted from disk either way — the difference is where the work happens. When you browse \\wsl.localhost\... in Windows Explorer, every single operation travels across a translation layer into the WSL virtual machine, one file at a time. rm -rf performs the same low-level deletions, but it never leaves the Linux filesystem, so each deletion costs almost nothing.
Two filesystems separated by a protocol bridge
WSL2 runs Ubuntu inside a lightweight virtual machine with its own real disk image formatted as ext4. Windows has no native way to read ext4, so WSL exposes the Linux tree to Windows as a network-style share under \\wsl.localhost\. Historically this share has been implemented with the 9p protocol, a mechanism designed for sharing filesystems between virtual machines and their hosts. Every action Explorer takes — listing a directory, reading metadata, deleting a file — becomes a request that is packaged, sent into the VM, executed by Linux, and answered.
Why Explorer's delete takes minutes
Deleting a deep node_modules tree through this bridge is close to a worst-case workload:
- No filesystem offers a "delete this entire tree" operation. Explorer must walk the directory structure and remove files one by one, and it usually enumerates and measures everything first to display progress.
- Each of those steps is a separate round trip across the 9p boundary, with protocol overhead and scheduling on both sides.
- A typical web project can contain tens of thousands of small files in deeply nested paths, multiplying the number of translated calls.
- The errors you saw along the way usually stem from Windows path-length limits, permission bits that do not map cleanly between the two systems, or files still held open by a running process.
Why rm -rf finishes in about a second
The Linux command has no magic shortcut either: it walks the tree and issues an unlink() for every file and a rmdir() for every directory. The crucial difference is that all of those calls are native syscalls executed directly against ext4 inside the VM. There is no protocol, no translation, no round trip — just local metadata updates that take microseconds each. Multiply that by tens of thousands of files, and the gap between seconds and minutes appears.
The reverse direction is just as slow
The penalty is symmetric. Inside Ubuntu, the Windows C:\ drive appears at /mnt/c, which is also a translating filesystem. Running rm -rf against a folder under /mnt/c/Users/you/Downloads from the Linux terminal is slow for exactly the same reason: each operation must cross the boundary into Windows. The direction does not matter — crossing the boundary does.
How to avoid the slowdown
- Keep Linux projects and their dependencies in the Linux filesystem, for example
~/projects, and manage them with Linux tools. Delete withrm -rf. - Keep files you use from Windows tools (PowerShell, Explorer, Visual Studio) on the Windows filesystem, for example
C:\Users\you\.... - If you must remove a Linux-side folder while working in Windows, skip the GUI. From PowerShell, run:
wsl -- rm -rf ~/projects/my-app/node_modulesThis sends the command straight into the VM, so the deletion happens natively at full speed.
- Reserve
\\wsl.localhost\for occasional browsing or copying individual files, not bulk operations.
Newer WSL releases are replacing 9p with virtiofs, a faster sharing mechanism that narrows the gap considerably. Even so, cross-boundary access remains slower than native access, which is why Microsoft's guidance stands: store your files on the side whose tools you are actually using.
Frequently Asked Questions
Does deleting through Explorer actually remove the data?
Yes. Each file is eventually unlinked inside the WSL disk image; the operation is merely slow, not cosmetic. If Explorer reported errors, a few entries may have survived, so a follow-up rm -rf from Linux is a sensible cleanup.
Why is the same folder fast to delete from the Ubuntu terminal?
Because the terminal's rm runs inside the VM against ext4 directly, issuing native unlink() calls with no protocol translation in between.
Is /mnt/c slow for Linux tools too?
Yes. It is the same translation layer operating in reverse, so builds or rm -rf pointed at /mnt/c suffer the same per-file overhead.
Will virtiofs fix this completely?
It removes much of the overhead and makes cross-OS file access far faster, but native storage on the matching operating system will still be quicker. Treat virtiofs as an improvement, not an invitation to work across the boundary constantly.
Does this apply to WSL1 as well?
No. WSL1 has no virtual machine; its Linux files live on the Windows drive, so Explorer reaches them at close to normal NTFS speed. The slow bridge described here is specific to WSL2's VM-based design.
Why did Explorer show errors during the delete?
The most common causes are Windows path-length limits on deeply nested dependency trees, permission bits that do not translate cleanly between the two systems, and files still locked open by a dev server, editor, or file watcher.