3 ms·

C:\Users\Windows Username\AppData\Local\lxss\home\WSL username\.ssh ? Unless i'm misunderstanding the issue

• freeone3000 8y ago
  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 8y ago
  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 8y ago
    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 8y ago
    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.