Editing files in a Windows Subsystem for Linux development environment

Microsoft has recently added comprehensive support for this, and it should be generally available in the April 2019 (19H1) update. Once it's ready, a 9P server will run in the background whenever a Linux distro is running. The 9P server will be able to handle Linux filesystem metadata, and Windows will be able to treat it as a network drive so it can access it safely. You can read about it at https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/.

With the new feature, you'll be able to safely access both Windows and Linux filesystem files from Windows, as long as you go through the 9P server. This will be handled natively from within WSL. For example, from the WSL command line you'll be able to type code /mnt/c/Users/username/src/windows-file.txt to open a Windows file in VS Code, or type code /home/username/src/linux-file.txt to open a Linux file in VS Code.

If you're not part of the Windows Insider Program, you won't have access to this yet so you'll still have to use an older method, such as wslpath.

wslpath will convert between Windows- and Linux-style paths so you can easily open Windows files from the WSL command line. As per https://github.com/Microsoft/WSL/issues/3146#issuecomment-388118689, it will refuse to convert Linux filesystem paths (i.e. %AppData%\lxss), because without 9P it's unsafe to modify these files from Windows. This means you can't open /home/username/src/linux-file.txt, but you can use code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

In the past, there were a number of third-party tools to perform the same conversion but wslpath does it natively-- in fact, ls -l /bin/wslpath shows that it's just a link to /init.

In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:

• In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.
• Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.

Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.

I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is no better way to get the best of both worlds, other than the ones you have mentioned (that I know of).

I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make smoother, but it's not there yet.