access Linux symlinks from \\wsl$

[trentis]

Is your feature request related to a problem? Please describe. I want to be able to open a symlink from the '\wsl$\Ubuntu' directory. The reason for this Is I'm writing a program that would read an elf binary and import the required objects to run it inside the directory that the binary is in.

This is from a virtualization perspective the kernel we use is linux based and Im purely looking at a way to improve development of apps on Windows. The only thing I want to do with the files is be able to read them and copy to a location without any changes. But most elf objects link to shared libraries that are symlinks but Windows doesn't seem to know what to do with that file. Any sort of open on that file results in system could not find the name specified. I assume this is because the explorer is attempting to open the symlink but its at a path it doesn't understand like '/lib/64' instead of '\wsl$\Ubuntu\lib\64'.

Describe the solution you'd like Maybe on the file open in the windows explorer prefix it with the location of the symlink. '/lib/64' turns into opening '\wsl$\Ubuntu\lib\64' I imagine this would be a big task probably.

Describe alternatives you've considered I could probably resolve this from the perspective of installing another daemon on my subsystem and just do the calls there. I'm mainly querying about this so I can improve UX of our application and the user doesn't have to install two of the same thing.

Is there a use case where we could set the LD_LIBRARY_PATH on our Windows machine to point to one of the sub system shares?

Additional context Basically want to read the ldd of an elf binary copy the objects into a windows directory. Proceed to do that recursively for everything that binary requires.

[maicol07]

I'm currently using PHPStorm on WSL (through snap package) +  GWSL to develop and it's good for daily use (there are some issues sometimes with dialogs closing after they opened).

This issue has been here for a while and as a Jetbrains user working on WSL, I feel like I'm stuck between the silence of Microsoft here and the "we can't do anything unless this is solved in WSL" of Jetbrains.

@toyi actually, that's not really true. JetBrains is currently working on a new "WSL agent" which should be in charge of OS interaction. If this will work, we'll be able to use symlinks on the Windows IDE in a WSL project! I hope we'll be able to see it in the first 2023.2 EAP build.
Source: https://youtrack.jetbrains.com/issue/IDEA-293604/IntelliJ-is-slow-hanging-when-working-with-WSL-filesystem#focus=Comments-27-6939089.0-0

[Yolo-plop]

Gui apps just work fine in WSL. Just make sure your WSL installation is up to date (wsl --update in a Windows terminal), get Jetbrains toolbox for Linux, execute it from the terminal, install PHPStorm of whatever and call it from the terminal.

I also run Gitkraken directly in Linux GUI, there were problems with some file informations when trying to run it from Windows.

[toyi]

@toyi actually, that's not really true. JetBrains is currently working on a new "WSL agent" which should be in charge of OS interaction. If this will work, we'll be able to use symlinks on the Windows IDE in a WSL project! I hope we'll be able to see it in the first 2023.2 EAP build.

Indeed, I missed that and this is a pretty good news !

[AndrewBogdanovTSS]

2023.1 already has Remote Development feature that allows you to connect to WSL and run it in a proper context. The feature is in Beta now and is quite unstable but let's hope it will get better through time

[maicol07]

2023.1 already has Remote Development feature that allows you to connect to WSL and run it in a proper context. The feature is in Beta now and is quite unstable but let's hope it will get better through time

I know but it currently behaves as a separate IDE and it has some issues with plugins and themes and some features are missing from the local IDE (such as some fix suggestions).

[AndrewBogdanovTSS]

Yes, that's what I meant by "unstable" 🙂

[realjjaveweb]

So I still see no milestone, no assignee and mainly - no PR - what is the current state of this? This is still very much needed for working with it out of the box on Windows.

[oldium]

@benhillis Are there any plans to implement symbolic links through the wsl$ paths, please? Projects already started skipping creating symbolic links in WSL2 because of missing support when accessing the files from Windows. JetBrains IDEs also suffer from issues with symbolic links when using WSL2.

[haosmos]

Hi guys!

is there any news on this issue? many people have been waiting for a solution to this problem for many years.

[Anatolych97]

The moment when the company does not care about their users. They can't even officially refuse this functionality.

[mark-langer]

Hi @craigloewen-msft, I can see you're quite active in this repo. Is there any chance you could find the right person on the Microsoft team to reply to this thread? 🙏

[ryanjshaw]

Hello. In case it is of interest to you. How to access the WSL2 file system from Windows with Samba. Samba transforms symlinks into Windows folders, so symlinks don't present any problem for filesystem use from Windows. The article is written in Spanish, it is very easy to follow using the translator integrated into linkedin. Best regards https://www.linkedin.com/pulse/acceso-wsl2-desde-windows-con-samba-manuel-nicol%C3%A1s-ortu%C3%B1o/

This works pretty well as a tactical solution.

I've setup a .ps1 script to deal with the IP address changing:

# Get the IP address from WSL
$ip = wsl hostname -I | Out-String
$ip = $ip.Trim() # Remove any whitespace

# Map the drive. -Persist is necessary to expose the drive outside the PSSession.
New-PSDrive -Name S -PSProvider FileSystem -Root "\\$ip\shared" -Persist

This script works without explicit credentials if your Windows username/password matches your samba username and password.

The other option would be sshfs but that's not natively supported by Windows.

[drunkwolfs]

Есть новости по этой задаче?

[wursta]

It seems that Microsoft has given up on fixing this bugfeature...

[haosmos]

guys, hi! 😃

It will be great if this problem is solved! The community has been waiting for a solution to this problem for many years.

[popuguytheparrot]

turborepo with pnpm, yarn workspaces not working on wsl2 ubuntu image

[mohamedelkony]

+1

[Giovancruz]

+1

[Stanzilla]

@benhillis any chance this can get looked at?

[szpolny]

4 years later and still waiting

[Ruvik]

+1

[oldium]

There is a Subscribe button if you want to follow. Sending +1 to more than 200 people seems rude. Thanks.

[realjjaveweb]

There is a Subscribe button if you want to follow. Sending +1 to more than 200 people seems rude. Thanks.

It's not about follow, it's about saying "I too support this issue" for an issue that is not solved for 4 years.

It's about bringing attention and keeping the thread alive...

The issue is more and more pressing since symlinks are getting in volume.

[robere2]

There is a Subscribe button if you want to follow. Sending +1 to more than 200 people seems rude. Thanks.

It's not about follow, it's about saying "I too support this issue" for an issue that is not solved for 4 years.

It's about bringing attention and keeping the thread alive...

The issue is more and more pressing since symlinks are getting in volume.

I really hate to contribute to the email spam here, but giving a thumbs-up will push the issue closer to the top of the most popular feature request issues: https://github.com/microsoft/WSL/issues?q=is%3Aissue+is%3Aopen+label%3Afeature+sort%3Areactions-%2B1-desc

If you look there, you'll see this feature is currently the 8th-most requested feature for WSL. Sorting feature requests by most recently active is not exactly a good metric (at least in my opinion), partially for the reason mentioned above, but also because discussion != support. If you want to comment every couple months just to make sure it doesn't get regarded as fixed through some other means, fine... There is no need to consistently keep this issue on the front page of most-recently-updated feature requests. This is how issues get locked.

I have no authority in this regard, but I question whether this may violate the repository's Code of Conduct "disruptive behavior".

[sirredbeard]

This issue was brought to my attention on Twitter. I have no inside information on this, but I do have a theory as to why this issue persists/feature request is still outstanding.

Windows to WSL file sharing via the UNC path, e.g. \\WSL$\fedoraremix, is handled by 9p file server/client, part of the broader 9p network protocol. The WSL2 init process loads a 9p file server in the WSL distro and can be connected to via a driver in Windows, specifically C:\Windows\System32\drivers\p9rdr.sys.

This is not unlike the virtio implementation of 9p for QEMU and KVM.

9p is a very simple, fast, lightweight protocol for file sharing, which is descended from the Plan 9 operating system. It makes sense from a speed perspective to use over NFS or Samba and was much simpler to implement. 9p also avoids the GPL licensing issues that NFS and Samba would introduce.

The issue here, I suspect, is that the Plan 9 OS, and thus 9p, never adopted symbolic links from its predecessor, UNIX, which Linux was heavily influenced by, via MINIX.

Rob Pike, who worked on UNIX at Bell Labs, alongside Ken Thompson, with help from Dennis Ritchie, later worked on Plan 9 as a successor to UNIX which shed many of its complexities. Pike specifically rejected symbolic linking in Plan 9. You also know Pike as the inventor of Go.

A search of GitHub issues shows several other projects that implement 9p also lack symbolic link support, such as minikube.

WSL implements the 9p2000.l dialect of 9p, which is a lightweight subset of 9p2000 which specializes in data types relevant to Linux system calls, maps directly to the Linux file system, and provides speed enhancements for Windows to WSL file operations.

The alternative would be to implement the 9p2000.u dialect of 9p which does implement symbolic links, but would not include the Linux-specific enhancements and be more challenging to implement.

This appears to be a tradeoff made between simplicity/speed and full support for things like symbolic links. This is just my theory, but I wanted to provide some potential context to the discussion.