WSL treating symlinks as win32 junction (redux)

[therealkenc]

• Your Windows build number: (Type ver at a Windows Command Prompt)

19555 WSL 2 Ubuntu-18.04

• What you're doing and what's happening

Repro from #4867 is how I noticed:

$ echo hello > /tmp/foo
$ ln -s /tmp/foo /tmp/bar
$ cd /mnt/c  # quash interop warning
$ cmd.exe /c dir '\\wsl$\Ubuntu-18.04\tmp\bar'

Looks like this was brought up in October 2019, but no one inc myself would notice in a long closed issue.

• What's wrong / what should be happening instead:

Regress #353 (message). They were win32 symlinks (contrast junctions) as of 17046, as long as the user possesses SE_CREATE_SYMBOLIC_LINK_PRIVILEGE, which (quoth) "normally requires you to launch wsl.exe elevated), unless Developer Mode is turned on."

It is possible the definition of "developer mode" changed somewhere along the lines.

• Strace of the failing command

The syscalls succeed, natch.

[therealkenc]

It is possible the definition of "developer mode" changed somewhere along the lines.

Setting aside "Developer Mode", it might be possible we've lost "launch wsl.exe elevated" around the time WSL2 was released to Insiders. If WSL is started (invoked while in the stopped state) from an Admin cmd.exe, symlinks also appear as junctions on the win32 side. [Will spare the screencap, it looks the same.]

If this theory is correct, then some other elevated WSL1 functionality went down with it (CLONE_NEWNET ref #3282 (message) comes to mind). Need more investigation to confirm if this is the case.

[Taytay]

I'm not sure that I'm adding much to this conversation, but I just wanted to note that we are running into this when cloning a git repo inside of Ubuntu. This repo contains some symlinks, and these symlinks are not readable by the Windows side of things. This means that git on the Windows side of things gives all sorts of errors like:

> git diff --summary
some_symlink: Function not implemented
another_symlink: Function not implemented

In addition, there are plenty of Input/Output errors when trying to read said files from the windows side of things:

> type '\\wsl$\Ubuntu-18.04\home\taytay\some_symlink'

type : The name of the file cannot be resolved by the system.
At line:1 char:1
+ type '\\wsl$\Ubuntu-18.04\home\taytay\some_symlink ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ReadError: (\\wsl$\Ubuntu-1...some_symlink:String) [Get-Content], IOException
    + FullyQualifiedErrorId : GetContentReaderIOError,Microsoft.PowerShell.Commands.GetContentCommand

My ideal is to do 99% of my work from the Linux side of things, but use some Windows Git GUI tools to manage these Git repos, and this sort of mismatch is throwing a wrench in those plans.
I'm including some of the above in hopes that googling for WSL, "Function not implemented", git, and WSL might turn up this issue, which took me a while to find. :)

[tychedelia]

Ran into something similar while debugging intellij-rust/intellij-rust#1171. In this case, Java totally fails to read the symlink on the WSL fs. I originally thought this might just be an upstream bug in openjdk, but it appears that there is weird behavior on the Windows side:

I've barely used Windows, so apologies if I misunderstand how symlinks work on the platform, but it looks to me like the file attributes correctly recognize that this is a symlink, but all the metadata is null. I imagine Java is using this and thus thinks the file doesn't exist / is unable to follow the link.

[PrasadTamgale]

Try these workarounds until this issue is patched.

1. Cygwin 3.1.5 or Above is capable of resolving these reparse points showing as "[JUNCTION]" & helps resolve symlinks.
2. Migrate from 9P server to Samba server is WSL2 & access the share from \\localhost\<share> which also resolves the symlinks.

[donalhunt]

my issue regarding file permissions under linux changing seems to be due to DrvFS having metadata turned off by default. 🙄

[xmontero]

Is this question https://superuser.com/q/1695779/324451 the same than this bug?

[blami]

This does not work also for symlinks created on drvfs. I use WSL2 with home directory redirected to /mnt/C/Users/my_windows_user (it's slow but I need that).

When I create symlink inside WSL with ln -s /home/a b where a is directory, on Windows side (e.g. in cmd.exe) it shows as 04/07/2022 09:49 PM <JUNCTION> b [...] and it is not accessible from explorer.exe (gives an error C:\Users\my_windows_user\b is not accesible). When link is relative Windows explorer.exe shows icon as directory with link overlay while if link is absolute (still pointing from drvfs to drvfs) it shows as unknown file even if it's a directory.