WSL(ubuntu/windows) AppData\Local\Lxss doesn't actually sync back to ubuntu, ideas?

Question

If you create a file in bash (touch /root/foo.txt) that appears in the hidden directories in AppData\Local\Lxss\ modifying it there does not change it in bash. Worse if you change it again in bash the file you changed thru explorer gets clobbered!

Is there any real mount point on C:\ ?

Where's the real image hiding?? (like is the file system writing back to an image file in reality?)

0:14:29 in this https://channel9.msdn.com/Events/Build/2016/C906 seems to claim you will have full access from explorer. 0:16:30 they show you AppData\Local\Lxss\ but do not once mention that your files will not sync as I described.

Answer 1

New files that are created via Windows Explorer are possibly not appearing in bash because they are missing special LXSS NTFS attributes.

When LXSS creates files in the LXSS root, it attaches additional information to them via NTFS attributes to store things that cannot be represented by the standard NTFS attributes, such as Linux file permissions. If these are missing, it the files don't show up.

This is supported by the fact that if you make a file in bash, and then make a copy of it with Windows Explorer, it appears in bash. This is presumably because all of the special LXSS attributes were duplicated with the file.

The LXSS filesystem layer also appears to cache the file system, so the directory entries in bash will not reflect the actual state of the file system if files are added or deleted until all bash terminals are stopped (which ends the LXSS session in the LXSS service and hence clears the cache).

Answer 2

Ok it seems stuff at AppData\Local\Lxss\ is modifiable and will sync back to the Ubuntu bash session.

You must close bash completely. And you can not create new files.

Strange as Microsoft seems to say you can't.

However other than being annoying this is still not very usable as making new files doesn't seem to work.

I don't know if the bash session puts stuff into ram or what but Microsoft can make this happen it appears.. If they choose.

Answer 3

I think you will find this ... incredibly helpful. There is quite a lot of useful information there, but it can be summed up as it applies here in one section:

Interoperability with Windows

While VolFs files are stored in regular files on Windows in the directories mentioned above, interoperability with Windows is not supported. If a new file is added to one of these directories from Windows, it lacks the EAs needed by VolFs, so VolFs doesn’t know what to do with the file and simply ignores it. Many editors will also strip the EAs when saving an existing file, again making the file unusable in WSL.

Additionally, since VFS caches directory entries, any modifications to those directories that are made from Windows while WSL is running may not be accurately reflected.

The article does talk about the specifics of the filesystem and the extended attributes as well. But in summary, modifying WSL files from windows is a no-go.

Answer 4

What works for me is copying with bash instead of using Explorer.

The C-drive is at /mnt/c so in order to copy the folder C:\tmp\test1 to /tmp/ in your bash home directory do: cp -r /mnt/c/tmp/test1 ~/tmp.

Answer 5

Until they get this worked out, I installed cygwin sshd for visibility to the native NTFS file system and ran the ubuntu sshd for visibility to the lsxx linux files. use apt-get to install sshfs and win-sshfs to do mounts each way. It is a round-about hack but works for me for now.

If you didn't want to mess with the cygwin sshd, you could use cygwin ssh to scp the files back and forth.

Using cygwin sshd helps get around file permissions issues by using a real administrator account in the .ssh/config file. I had some strange access permissions going through the DevFS/NTFS interface.