Unify lxss symlinks and win32 symlinks on driveFS?

[fpqc]

The new builds have unprivileged symlinks available for us to play with in win32. WSL also does symlinking on DriveFS. However, when I made a DriveFS to DriveFS symlink from inside of WSL, this symlink appeared as a weird kind of file in Win32. (running dir in cmd said it was of type junction [...], although it appears to be an invalid junction, since it was not traversable in Windows Explorer or cmd).

It seems like a natural idea to have DriveFS-to-DriveFS symlinks created as actual NTFS symlinks now that they can be made without administrative privileges. Also of note: Trying to traverse a Win32 symlink inside of WSL produces the error:

Input/output error

Also, for obvious reasons, driveFS symlinks to VolFS/LXFS should maybe remain as they are (to avoid all of the weird and broken things that could happen), and VolFS-to-VolFS or VolFS-to-DriveFS symlinks are already a completely different format (they appear to be textfiles with special attributes if opened from a Win32 text editor).

[aseering]

This sounds like #559 ?

For what it's worth, I would like this feature, and I have heard from others who would also like this feature.

[fpqc]

@aseering This is the first build that enables unprivileged creation of symlinks (when in developer mode).

[aseering]

By "this build", do you mean r14986? Then it sounds like it's a good time to restart the discussion :-)

[fpqc]

@aseering Yup. Technically it was announced last week for the cancelled insider build 14972 (because of the switch to the new UUP updater).

https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#6rqVGez52fmdys8Q.97

[benhillis]

We've spoken about this internally and I agree it would be a nice feature to have. I'll check with the team about the current plan.

[fpqc]

@benhillis Also, by the way, if we try to traverse a Win32 symlink with WSL in DriveFS, we get the error:

Input/Output error

If I remember correctly, in the old pre-anniversary edition days, these kinds of symlinks were traversable. Also, the Win32 symlinks on DriveFS do not appear to even be visible with ls on drivefs

[vyv03354]

Although unprivileged create requires the developer mode, it does not matter to WSL because WSL also requires the developer mode anyway.

[fpqc]

@vy03354 yup!

[0xabu]

This would also help with Cygwin interop. Right now, there's no common symlink format understood by both Cygwin and WSL, which makes switching between Cygwin and WSL a painful all-or-nothing affair. Cygwin already has read support for NTFS symlinks.

[fpqc]

Hey 0xabu. I spoke to the msys2 irc channel and they're going upstream to have it changed there as well to use native symlinks on 14986 in dev mode.

[ayalon]

From the point of a web developer, the cross use of symlinks is one of the most important missing features of WSL. I'm constantly testing WSL and for now, this missing features is the only left blocker to completely switch from OSX to Windows 10. Maybe the performance of the mounted file system is also annoying, but it's not a show stopper.

Anykind of improvments so that symlinks are seen / shared between the two filesystem would be so much appreciated.

[DannyT]

What @ayalon said. We utilise grunt/gulp for various frontend dev setup/build processes which all works flawlessly in WSL with the exception of symlinks that are created. Windows not being able to follow symlinks created in WSL is the only show-stopper for our company-wide adoption.

[MatrixDev]

I have similar problem developing on Android because of "repo" utility. It manages tons of git repositories at once (which is required in my case). Problem appears because all files in ".git" folder are links to actual files in ".repo" folder. Because of this it is impossible to use git on windows side...

[ayalon]

@benhillis: Will this be considered for the Creators Update? THis would solve us sooo much headache.

[JFLarvoire]

lxss symlinks 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.

[vyv03354]

Although unprivileged create requires the developer mode, it does not matter to WSL because WSL also requires the developer mode anyway.

This no longer holds. Since build 16215, WSL can run without developer mode enabled.

Another change: Since build 16193, WSL can follow already created NT symlinks. But it is still not possible to create a new NT symlink.

[131]

Any update here ?
This is also restraining my team for the switch :/

[sunilmut]

@SvenGroot was working on this one and might be able to provide updates.

[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 /D 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 /D 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

[ayalon]

NTFS junctions work since almost a year. The issue is, that symlinks created inside WSDL result in an unreadable file on the NTFS side.
This is the remaining task in this thread.

Tools like composer or modman from magento create tons of symlinks but these do not work on NTFS.

The missing piece is this:

ln -s {/path/to/file-name} {link-name}

readable on NTFS.

[Brian-Perkins]

Windows Insider Build 17046 contains some improvements for symlink compatibility. See the full description in the release notes

[heldchen]

awesome, works great!

[ayalon]

I can wait to test this. This sounds really really awesome!

[tara-raj]

Closing as this issue is fixed in Insiders Build 17046 as mentioned above #1475 (comment)

[safizn]

Closing as this issue is fixed in Insiders Build 17046 as mentioned above #1475 (comment)

@tara-raj Hi, does that mean that WSL symlinks can be opened with a native Linux container/VM ? I'm trying to do so but cannot seem to get it working.
#3611
Help !

[RDeluxe]

I don't think @myuseringithub issue is the same as depicted here.
It's not a case issue.

[pyldin601]

Update: Fixed by enabling Windows Developer Mode

Windows Build 18362.592
I have problem with Rush-managed monorepo inside WSL. It makes symbolic links inside WSL, which is unreadable from Windows IDE.

C:\Users\roman\WebstormProjects\...\node_modules>dir
 Volume in drive C is OS
 Volume Serial Number is DE9A-DCBC

 Directory of C:\Users\roman\WebstormProjects\...\node_modules

01/31/2020  09:46 PM    <DIR>          .
01/31/2020  09:46 PM    <DIR>          ..
01/31/2020  09:46 PM    <DIR>          .bin
01/31/2020  09:46 PM    <JUNCTION>     koa [...]
01/31/2020  09:46 PM    <JUNCTION>     koa-body [...]
01/31/2020  09:46 PM    <JUNCTION>     koa-router [...]
01/31/2020  09:46 PM    <JUNCTION>     nodemon [...]
01/31/2020  09:46 PM    <JUNCTION>     parse-strings-in-object [...]
01/31/2020  09:46 PM    <JUNCTION>     rc [...]
               6 File(s)              0 bytes
               4 Dir(s)  80,805,060,608 bytes free