microsoft / microsoft/WSL

Windows symlinks (mklink) on drvfs pointing to \\wsl$\... should resolve in WSL

Open
#8,385 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.