NTFS Junctions not seen by WSL

[ned14]

In a Windows command box in Administrator mode:

mkdir foodir
echo > foo
mklink /j temp1 foodir
mklink /d temp2 foodir
mklink temp3 foo

In WSL:

ls -l
total 208
drwxrwxrwx 2 root root 0 Jul 14 11:40 .
drwxrwxrwx 2 root root 0 Jul 12 08:28 ..
-rwxrwxrwx 2 root root 0 Jul 12 08:45 foo
drwxrwxrwx 2 root root 0 Jul 12 08:45 foodir

Looks like NTFS junction points and NTFS symbolic links are completely invisible to WSL code :(

It would be really super if this could be fixed. I understand from #353 why NTFS symbolic links can't be created by WSL, however WSL should be able to understand Windows symbolic and junction point types on anything inside /mnt/* for compatibility with Windows.

[mmthomas]

See #559, its on the backlog.

[SteveALee]

When I create a symbolic link in WSL (ln -s) with a target also under /mnt/c it appears as a Junction but with empty contents - at least it does not point to the same place on the window side.

I'd like to use for npm package development when linking to another package in WSL and using @code in windows

[SteveALee]

Is there any news on this and syncronising links and junctions in general? I really want to use wsl with npm and VS Code but this is a blocking issue

[131]

mklink (NTFS junctions) are seen as symlink in WSL (fall creator update 1709)

But beware that it's case sensitive, and WSL cares about it.

mklink /J node_modules D:\dvp\node_modules\async 
dir node_modules 
<JUNCTION>     async-co [D:\dvp\node_modules\async-co]
=> seen as symlink to /mnt/d/dvp/node_modules in WSL

Whereas

mklink /J node_modules d:\dvp\node_modules\async  (note the lowercase D)
dir node_modules 
<JUNCTION>     async-co [d:\dvp\node_modules\async-co]  (works in windows)
=> invalid link in WSL

[benhillis]

Closing as fixed in 1709.

[SteveALee]

Time to use VS code and wsl then :)