[hackujin]

I just don't want to use Windows to test my code when production is in Linux. There are things all those tools do when running in Windows that is specific to Windows. And I'm not some anti-windows Microsoft hating guy. My main desktop is running Windows 10 and I was quite excited for WSL to come out so I had Windows 10 Insider Preview running on my machine for more than a year. But at the end of the day when I want to do "real" work I keep going back to my Macbook.

Windows command prompt compared to bash is simply horrible. I personally find Powershell to be just as bad. The console app in windows is still light years behind Terminal in OS X. In fact VSCode's built in terminal wrapper is orders of magnitude better.

Things like wkhtmltopdf to generate PDFs or ffmpeg to work with videos should run as they do in Linux on the production server. In OS X I can use brew to set things up. In windows I have to hunt down binaries, put them in the right place, and set the path manually via an OS level GUI many clicks down in Advanced Settings.

The extra work I need to do to make all those tools work in windows makes setting up a windows dev environment cumbersome and annoying. The way it's laid out in OS X gives me way cleaner interoperability with the way the code actually runs in a Linux environment.

It's one of the reasons I love WSL! Finally I can have a ~/.ssh/config in Windows! But I still can't edit the file from a Windows text editor.

Finally if I'm on a team where the production environment relies on some of these linux binaries being available I don't want to waste work hours researching and writing on boarding documentation for the one dev that feels like working in windows when the rest of us are on macs.

[dbetteridge]

C:\Users\Windows Username\AppData\Local\lxss\home\WSL username\.ssh ?

Unless i'm misunderstanding the issue

[freeone3000]

Stuff in lxss is treated "special" - files in that directory have unix numeric permissions on NTFS instead of ACL permissions. Windows doesn't know how to set those, so if win32 subsystem is updating permissions (for instance, on file save) and the linux subsystem is updating metadata (for instance, on file save), it's possible to end up in a state where neither subsystem is able to get permission to touch the file again.

For this reason, it is recommended to only edit files outside this directory from both subsystems (not to say this isn't issue-free, but it's relatively reliable.)

[hackujin]

The file becomes invisible to WSL right after it gets edited in Windows. It's because it's doing weird tricks to associate UNIX permissions to files stored in Windows. The Windows app will break those permissions so instead of mitigating that in WSL it simply stops being able to "see" the file.

[freeone3000]

There's a perf hit. You may have noticed disk access in WSL outside this directory is slow. Inside this directory, wsl should be the same speed as w32 native, because it doesn't hit the magic layer.

[arbie]

Do you have more detail about this? I edit files in VSCode/Notepad++ and execute them in WSL daily and have never run into this issue.

[voltagex_]

Would drvfs and symlinks solve your issue with ssh and npm?