Junction points on NTFS volumes (mklink /j) not seen in DriveFS

[mmthomas]

DriveFS doesn't seem to see or traverse NTFS junction points. Here is the sample command line / bash session. The junction point junc doesn't show up in the bash session.

C:\Users\monro\OneDrive\Saved Games>ver

Microsoft Windows [Version 10.0.14367]

C:\Users\monro\OneDrive\Saved Games>dir /a
 Volume in drive C is System
 Volume Serial Number is 4203-D40A

 Directory of C:\Users\monro\OneDrive\Saved Games

2016-06-20  09:12 AM    <DIR>          .
2016-06-20  09:12 AM    <DIR>          ..
2016-06-17  06:11 PM               282 desktop.ini
               1 File(s)            282 bytes
               2 Dir(s)  163,485,835,264 bytes free

C:\Users\monro\OneDrive\Saved Games>mkdir test

C:\Users\monro\OneDrive\Saved Games>mklink /j junc test
Junction created for junc <<===>> test

C:\Users\monro\OneDrive\Saved Games>dir /a
 Volume in drive C is System
 Volume Serial Number is 4203-D40A

 Directory of C:\Users\monro\OneDrive\Saved Games

2016-06-20  09:13 AM    <DIR>          .
2016-06-20  09:13 AM    <DIR>          ..
2016-06-17  06:11 PM               282 desktop.ini
2016-06-20  09:13 AM    <JUNCTION>     junc [C:\Users\monro\OneDrive\Saved Games\test]
2016-06-20  09:12 AM    <DIR>          test
               1 File(s)            282 bytes
               4 Dir(s)  163,485,765,632 bytes free

C:\Users\monro\OneDrive\Saved Games>bash
monroe@DEV-MONROE:/mnt/c/Users/monro/OneDrive/Saved Games$ ls -la
total 4
drwxrwxrwx 2 root root   0 Jun 20 09:13 .
drwxrwxrwx 2 root root   0 Jun 20 08:26 ..
-rwxrwxrwx 1 root root 282 Jun 17 18:11 desktop.ini
drwxrwxrwx 2 root root   0 Jun 20 09:12 test
monroe@DEV-MONROE:/mnt/c/Users/monro/OneDrive/Saved Games$

[mmthomas]

Not sure if this is a dupe of #201 or not (not enough info in that issue), but it's the closest one I could find. If the fix for #201 is relevant, I guess it hasn't made it into the Fast ring as of build 14367.

[dethoma]

This is by design for the anniversary edition. Today Windows symlinks/junction points remain visible only inside Windows and Linux symlinks created inside WSL remain visible inside WSL. They are not accessible to each other.

Two primary reasons

1. The name spaces in Windows and Linux are different. There are volumes in Windows not accessible by WSL yet, think FAT partitions, removable volumes etc. Similarly there are Linux virtual file systems like /proc not accessible from Windows.
2. Linux symlinks are created by WSL using a custom reparse point which Windows does not compute and WSL ignores all other reparse points.

Open to revisiting the decision based on user feedback in the future.

[jamesdavidhoward]

The "By Design" response should definitely be considered temporary / a workaround. The Windows NTFS implementation of - for example - symlinks - is perfectly fine, and should be completely interpretable as WSL symlinks. Junctions can be viewed as a primitive symlink that happens to be an absolute pathname link text - and is easily reversibly translated.

The current status of "by design" implies limited interoperability of the 2 subsystems, improving the value of just using Linux in a VM.

[mmthomas]

@dethoma @benhillis thanks for the response. Based on #201, I wasn't sure whether this was by design or a bug, but I can understand it being a limitation for the Anniversary release. In the future it would be nice if WSL at least tried to parse a greater subset of reparse points (eg, junction points) and errored out if the target volume type is not compatible with DrvFS.

[benhillis]

@jamesdavidhoward As Deepu alluded to, we're nearing the release of the Windows 10 anniversary update and unfortunately that means that we will not have time to address every issue on this forum in the update. I would highly recommend visiting our user voice page and making your voice heard there about the features you'd like us to work on in future releases.

[jamesdavidhoward]

I concur with the prior comment about acceptability of improving handling
and visibility of junctions (and symlinks and hardlinks) after the
"Anniversary Release". My expectation, based on importance and frequency
of requests for this, is to see:
1.) a commitment to improve this
2.) identify it as "fix future" or (something like) "after Anniversary"

The current responses are non-responses; the kind of thing that would get
me a frown from my Intel managers...

---

James D. Howard, jhoward@alumni.caltech.edu

[aseering]

@jamesdavidhoward -- I can't speak for Microsoft specifically (haven't worked there in a long time), but I've previously posted professionally/regularly on a technical forum on behalf of HP. If I had given "real" answers on that forum, in the sense that you're referring to, I would have gotten much worse than just a frown from any of my managers :-)

Answers posted by employees to a public forum can have legal and contractual significance in terms of revenue recognition, etc. I've seen (not on said HP forums) a large team at a major tech company thrown months off schedule because of one incorrect comment somewhere on the Internet by a low-level employee that a customer interpreted as a commitment. I imagine you've encountered the same in your years at Intel too.

So, if you want a decision, talk to a PM, and wait in line while they process your request :-) My experience here (though anyone who actually works at Microsoft is of course welcome to correct my understanding) is that such commitments have been more forthcoming on the UserVoice forum, which I think is better designed to gather feedback on broader issues that thousands of people care about in different ways.

In contrast -- this github site seems to get responses directly from Microsoft engineers. Exactly the people who my manager would have wanted to not make public commitments on the Internet :-) But if you've got a specific bug or technical question and you want an answer right now, nothing beats a direct line to the people who know the code.

[mmthomas]

Reopening while on backlog.

[aseering]

If anyone would like this functionality, there's a UserVoice for it; go here to up-vote:

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13351308-junction-support

[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

(edited per @SteveALee remark, mklink /J (not /D) )

[SteveALee]

/D creates a SYMBLINKD not JUNCTION, as expected - but it works

However, I Find the reverse doesn't seem to work. Should it? Could it?

ln -s desktop3 /mnt/c/Users/steve/Desktop is seen as this in cmd dir
<JUNCTION> desktop3 [...]
where ... is expected to be C:\User\steve\Desktop
and access fails to see the desktop contents.

[tara-raj]

This is fixed as of Insiders build 16215 - https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-16215

[d3x0r]

This is not fixed.

I see that in in 16215 'Support directory junctions in drvfs.' sounds like someone thinks this works...

But today...

[panther@panther-pc sack]$ ls -ls /mnt/c/general
ls: cannot read symbolic link '/mnt/c/general/android': Input/output error
ls: cannot read symbolic link '/mnt/c/general/android.x': Input/output error
ls: cannot read symbolic link '/mnt/c/general/build': Input/output error
ls: cannot read symbolic link '/mnt/c/general/build.other': Input/output error
ls: cannot read symbolic link '/mnt/c/general/work': Input/output error
total 0
0 lrwxrwxrwx 1 root root 0 Aug  4 09:31 android
0 lrwxrwxrwx 1 root root 0 Dec 19  2017 android.x
0 lrwxrwxrwx 1 root root 0 Dec 19  2017 build
0 lrwxrwxrwx 1 root root 0 Dec 19  2017 build.other
0 lrwxrwxrwx 1 root root 0 Dec 15  2017 work
[panther@panther-pc sack]$ ls -ls /mnt/c/general/work
ls: cannot read symbolic link '/mnt/c/general/work': Input/output error
0 lrwxrwxrwx 1 root root 0 Dec 15  2017 /mnt/c/general/work
[panther@panther-pc sack]$ ek

C:\general>dir
 Volume in drive C is OS
 Volume Serial Number is F27E-3A0D

 Directory of C:\general

08/04/2018  08:31 AM    <DIR>          .
08/04/2018  08:31 AM    <DIR>          ..
08/04/2018  08:31 AM    <JUNCTION>     android [\??\Volume{c528513d-e5a0-45f2-9cb6-324aaf67eea9}\]
12/19/2017  10:59 AM    <JUNCTION>     android.x [\??\Volume{bf7cb924-0000-0000-0000-100000000000}\]
12/19/2017  10:55 AM    <JUNCTION>     build [\??\Volume{30204767-0000-0000-0000-100000000000}\]
12/19/2017  11:03 AM    <JUNCTION>     build.other [\??\Volume{4523f244-19b2-4fb6-9b4d-32a31ddd458f}\]
12/15/2017  07:11 PM    <JUNCTION>     work [\??\Volume{3020476d-0000-0000-0000-100000000000}\]

[zirahvi]

When will this be fixed? It is still broken (WSL2, Windows 10 build 19041).

[TheChilliPL]

Still broken on WSL 2 (Debian) with Kernel 5.10.43 on Windows 11 22449.rs_prerelease.210827...