When in the WLS $HOME directory, files created in a Win 10 cmd.exe are not usable in bash

[Neurogami]

Some editing tasks are easier when done in WIndows 10 directly (either via File Manger or a cmd.exe shell). However, files created in c:\Users\AppData\Local\lxss\home cannot be edited in WLS bash.

An example:

I open cmd.exe and cd to c:\Users\james\AppData\Local\lxss\home\james

I create a new file:

  c:\Users\james\AppData\Local\lxss\home\james>vi win10-test.txt

I add some text and save the file.

I then open a WLS bash session; I'm in my home folder by default.

I expect to see my new file (win10-test.txt) and to be able to edit in in bash. However, this file is not visible (ls -ltra does not show it).

If I attempt to edit it by name I get what seems to be a new file

    james@JAMES11:~$ vi win10-test.txt

And in vi I have this at bottom:

   win10-test.txt" [New File]   

If I add text and attempt to save this file I get an error from vi:

 "win10-test.txt" E212: Can't open file for writing      

I'm using Windows 10 Version 1607 OS Build 14393.321

Even odder: I can create a new text file in the bash shell, and then, back in cmd.exe, I can see that file, edit, add new text, and then save it. But when I re-open that file back in bash the new text is not visible. And then I can no longer save that file in bash.

[fpqc]

By design, lxss is hidden for a reason. Windows programs will strip the special attributes of those files that correspond to the Linux permissions and extra data.

[rodrymbo]

One possible workaround (for now) is to set up sshd (or maybe ftp) in WSL and use a Windows editor (or other program) that knows how to access files by that protocol. Or one can copy the file to a folder that begins with /mnt/ and edit it there, then copy it back from within the bash.exe environment. As long as all file writes are from within the WSL environment, the file should remain accessible from within the WSL environment. If you write to a file in lxss from outside the WSL environment, it will almost certainly become inaccessible from within WSL in the ways you describe.

Just pretend you don't know how to find that lxss directory from Windows.

[Neurogami]

I'll see how shuffling files via a temp folder outside lxss works. Perhaps coordinate using rsync inside WSL. And look at having gvim use ftp or ssh .

[rodrymbo]

I wonder which Windows text editor will be the first to figure out how to replicate enough of the extended attributes to be able to edit (or even create) files in the VolFS (or whatever they are calling it this week)?

[fpqc]

@rodrymbo Rolisoft wrote an extended attribute lib with python bindings, wouldn't be hard to make a vscode plugin probably.

[Neurogami]

"I wonder which Windows text editor will be the first to figure out how to replicate enough of the extended attributes ..."

But that leave the larger issue of being dependent on specific editors. And I'm not holding my breath waiting for a vi addition for this :)

[tara-raj]

Closing as a duplicate of #1524