Windows symlinks (mklink) on drvfs pointing to \\wsl$\... should resolve in WSL
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 33.7k
- Forks
- 1.8k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 116
Description
Version
Microsoft Windows [Version 10.0.22000.613]
WSL Version
- WSL 2
- WSL 1
Kernel Version
5.10.102.1-microsoft-standard-WSL2
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
On Windows:
cd C:\Users\blami
mklink /d src \\wsl$\Ubuntu\home\blami\src
In WSL2:
cd /mnt/c/Users/blami
ls src
Expected Behavior
src on drvfs (9p) resolves correctly as a symlink that points to /home/blami/src in same (or another) distribution. If I do not have rights to access that directory on Linux side, then its fine. Even limiting scope to just same distribution would be fine.
TL;DR explanation: I do not want to have different set of profiles for Windows and WSL (ssh keys, gpg keys, various configs for things like editor, scripts, etc.) so I usually change my home directory in WSL to /mnt/c/Users/blami. That slows down some tools that read configs from home (on WSL) but its acceptable price for not having syncing chaos between two environments. While I learned to live with regression making symlinks created on WSL side no longer work on Windows side, I cannot use NTFS drive for programming projects as it is too slow and Microsoft is not doing much with drvfs/9p perfomance since WSL2 came out. So to workaround I want to put my programming projects to src/ on WSL VHD and symlink that directory to my %USERPROFILE% so that all my projects are accessible from same place in both WSL and Windows without 9p performance cost on WSL side (I expect accessing them from Windows will be hit which is better as I usually only look at them/edit them on Windows, but never build). This is not possible because only Windows side understands \\wsl$\... symlinks.
Actual Behavior
ls: cannot read symbolic link 'src': Input/output error
Diagnostic Logs
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Windows mklink reproduction and the WSL2 /mnt/c drvfs path, then investigate how drvfs/9p handles symlinks targeting \wsl$ paths. Done means ls src resolves to the target Linux directory, including a same-distribution target, instead of returning an Input/output error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100