Carried over from wslkit/wslkit#29, the index of WSL pain points mined from microsoft/WSL. These five are filed here rather than there because they are filesystem behaviour, which means they belong to whatever serves the path, and the Plan 9 server behind \wsl.localhost cannot be extended from user land. A wsldrive mount can do all of them.
Vote counts re-checked against the upstream issues on 2026-09-14; every one is still open.
| Gap |
Upstream |
Votes |
Why it is ours |
| Linux symlinks are not resolved when serving to Windows |
microsoft/WSL#5118 |
314 |
Open six years, 134 comments. A WinFsp filesystem decides what a reparse point looks like. |
No byte-range locking, so LockFileEx fails |
#4689, #5762 |
107, 25 |
Breaks SQLite, Office, anything with a lock file. WinFsp exposes the lock callbacks. |
| Dotfiles are not marked hidden |
#6460 |
42 |
One attribute at enumeration time. |
Alternate data streams are accepted, so Zone.Identifier files appear inside the distribution |
#7456, #4609 |
399, 157 |
Refusing ADS writes means they are never created. wslkit can only clean them up afterwards (ZON001 and fix zone). |
| Metadata operations are slow |
#41480 |
2026 |
Plan 9 measured at roughly 26x native on metadata; a Windows-side attribute cache is the answer. |
Related, and the reason this list exists as one issue rather than five: file-change notification. Windows edits under /mnt/c never fire inotify, and Windows watchers on \wsl.localhost get no ReadDirectoryChangesW events (microsoft/WSL#4739, 513 votes). Windows-to-Linux cannot be fixed from user land at all, because inotify events are generated by the kernel when a real operation hits the inode and there is no API to synthesise them. Linux-to-Windows can: WinFsp has FspFileSystemNotify, so a wsldrive mount can raise real change notifications. wslkit tracks the diagnosis half in wslkit#37; the forwarding belongs here.
Split into separate issues when one is picked up. Nothing here is a commitment; it is the list of what a faster path could also make correct.
Carried over from wslkit/wslkit#29, the index of WSL pain points mined from microsoft/WSL. These five are filed here rather than there because they are filesystem behaviour, which means they belong to whatever serves the path, and the Plan 9 server behind
\wsl.localhostcannot be extended from user land. A wsldrive mount can do all of them.Vote counts re-checked against the upstream issues on 2026-09-14; every one is still open.
LockFileExfailsZone.Identifierfiles appear inside the distributionZON001andfix zone).Related, and the reason this list exists as one issue rather than five: file-change notification. Windows edits under
/mnt/cnever fire inotify, and Windows watchers on\wsl.localhostget noReadDirectoryChangesWevents (microsoft/WSL#4739, 513 votes). Windows-to-Linux cannot be fixed from user land at all, because inotify events are generated by the kernel when a real operation hits the inode and there is no API to synthesise them. Linux-to-Windows can: WinFsp hasFspFileSystemNotify, so a wsldrive mount can raise real change notifications. wslkit tracks the diagnosis half in wslkit#37; the forwarding belongs here.Split into separate issues when one is picked up. Nothing here is a commitment; it is the list of what a faster path could also make correct.