Symlinks on the mounted Windows directories are not compatible with native.

[tinysun212]

On build 14341,

I created a symbolic link to a file on a mounted Windows directory in BASH.

tinysun@TEST-PC:/mnt/c/Temp$ ln -s origfile.txt symlink.txt
tinysun@TEST-PC:/mnt/c/Temp$ ls -l
total 0
-rwxrwxrwx 1 root root 39 May  4 01:48 origfile.txt
lrwxrwxrwx 1 root root 12 May 13 02:58 symlink.txt -> origfile.txt
tinysun@TEST-PC:/mnt/c/Temp$

In the command prompt CMD.exe, the file appeared as a JUNCTION and can not be accessed.

C:\Temp>dir
 Volume in drive C has no label.
 Volume Serial Number is EAE0-0FD9

 Directory of C:\Temp

05/13/2016  11:58 AM    <DIR>          .
05/13/2016  11:58 AM    <DIR>          ..
05/04/2016  10:48 AM                39 origfile.txt
05/13/2016  11:58 AM    <JUNCTION>     symlink.txt [...]
               2 File(s)             51 bytes
               2 Dir(s)  194,170,494,976 bytes free

C:\Temp>type symlink.txt
The file cannot be accessed by the system.

C:\Temp>

It should be displayed as follows.

05/13/2016  11:58 AM    <SYMLINK>     symlink.txt [origfile.txt]

I think the 'JUNCTION' can be used when the link references a directory not a file.

[vyv03354]

Looks like cmd.exe does not (yet?) know WSL symlinks and it treats every unknown reparse point as a junction. But actually this is not a junction. It is a new type of reparse point whose reparse tag is 0xA000001D. Hopefully it will be documented in the future Windows 10 Anniversary SDK.

Unlike Windows symlinks/junctions, no filesystem/filter drivers resolve WSL symlinks automatically. I guess this is an intentional decision to prevent Windows apps from bypassing SeCreateSymbolicLinkPrivilege by using WSL symlinks.

[russalex]

I do owe some documentation on this one. Should get that up in the next few days.

@vyv03354 is correct that the primary reason we are not adding symlinks to Windows is because of the privilege required. As of now, symlinks created in WSL are only usable within WSL. This is something we will be looking at in later releases.

[ned14]

@russalex Can it not be the case that if the user running WSL has the SeCreateSymbolicLinkPrivilege that WSL creates NTFS format symbolic links instead of a custom link type?

[russalex]

Sven covers this question a little bit in his video on the WSL File system Blog post. There have been some discussions on doing this in the next release, but there are some questions and behavior that we would need to work out first.

I know there is a user voice page on this very request. Right now it only has 3 votes.

[ricketyboo]

Personally, coming from Linux and OSX the entire SeCreateSymbolicLinkPrivilege situation is one that has repeatedly caused me headache and grief. I was hoping against hope that BoW would finally fix the issue but, alas, it seems instead of making symlinks work properly in user space, MS has decided to just make a new standard? I can't follow any of the symlinks created in the linux subsystem even in windows exporer, much less in my IDE or other windows host apps. This makes me sad. :(

[ned14]

@rcuddy It is very straightforward to award any user group the SeCreateSymbolicLinkPrivilege and then you can create symbolic links to your heart's content! Note that any user with the ability to escalate to administrator still cannot create links, so you'll need to make your user an ordinary user, not administrator capable user for this to work.

[ricketyboo]

@ned14 Sure, I can add that privilege, but as you've pointed out, I then lose the ability for that user to escalate privileges. That doesn't seem a fair trade. ;)

[CherryDT]

Is there any workaround to this issue? I now ran into a problem there when I tried to do a backup of a folder using robocopy. It's a development folder and npm (under WSL) created a few symlinks from node_modules/.bin/xxx to something, and now robocopy chokes on these "files" because it perceives it ias "access denied" and keeps retrying - which is something I would like to have for files actually looked or so, but not for "broken" symlinks, so I would prefer not to have to disable the error handling in robocopy...

[JFLarvoire]

Repost of the suggestion I just posted on Issue #1475:

lxss symlinks also break my win32 backup tools.
+1 for the urgent need to unify lxss symlinks and win32 symlinks.

The tools on both sides of the programming world should be able to view and copy directory trees created on the other side, with all links in the copy usable by both sides as well.
=> The win32 and Linux subsystems must hide to user-mode programs what target path is really written on disk, and instead return to them converted targets they can understand.
For relative links this is pretty straightforward: Simply change all slahes to backslashes for the Win32 SS, or forward slahes for the Linux SS.
For absolute links, the problem is that the targets don't refer to the same root. Yet that root can be identified by the kind of slash written by the link creator:

• If the link contains back slashes, it was created by a Win32 process relative to a Windows volume.
• If it contains forward slashes, it was created by a Linux process, relative to the Linux FS root.

Then the subsystems can convert the link targets to absolute paths formatted as their respective user-mode programs expect.

[noinkling]

Would also like to see this. I've tried it both ways (link and target both on Windows file system):

1. Creating a symlink via ln -s from Bash/WSL.
2. Creating a symlink via mklink in Windows cmd.

With approach 1 I observe the behaviour mentioned here. Also the link will simply not appear in my editor on the Windows side (VS Code). In Windows Explorer it will appear but give an error upon trying to open it. However it works with everything on the WSL side.

With approach 2 everything works on the Windows side (as you would expect), but the symlink isn't visible and doesn't work on the WSL side. However, subsequently trying approach 1 results in this error: ln: failed to create symbolic link 'link.txt': File exists, and doing an rm will actually remove it, so it does exist at some level in WSL.

So to sum things up, a symlink created on either side cannot be effectively utilised by the other side, kinda breaking the file system interoperability promise. I would expect DriveFS to correctly handle symlinks created with mklink at least.

Thanks for your consideration.

[chx]

Yes, this a big mess especially when git gets involved....