changes made in Windows File System - not seen in Bash

[doctordns]

If I create a folder /mnt/c/foo in Bash, I can see that folder in Windows. If I create a file in that folder, say /mnt/c/foo/foo.txt - I can see it in Windows. BUt if I change it, the changes are not seen in Bash. ANd if I create a file c:\foo\foo2.txt - I can't see it in Bash.

[russalex]

Having a difficult time reproing this one. Just tried:

mkdir /mnt/c/foo
Windows Explorer - navigated to foo and created foo.txt
Opened in notepad and added content
$more foo

The content looked to show up correctly. Any chance you can give a bit more on the repro steps?

Note that we know there are some issues here if you go into your lxss directory and add files to your home dir. In this case it's possible to add directories or files that do not show up in Bash. I'll need to add those cases to the FAQ.

[okuoku]

Just wanted to say "me too" here, my steps were:

1. Install cygwin64
2. On WSL Bash: Checkout some GitHub repository to /root (Using Ubuntu git), then reboot the system
3. On Cygwin: Chdir to $LOCALAPPDATA/lxss/root
4. On Cygwin: Chdir to checked out repository in 2. and edit some file
5. On WSL Bash: Edit the same file, but you won't see changes made in 4
6. On Cygwin: Even if edited the file in 5., you will see 4. state on Cygwin

[dethoma]

@okuoku your scenario is a bit different. We do not support modifications to files in the lxss folder outside the WSL environment.

[johnwcowan]

The basic Cygwin vs. UoW issue turns out to be that when Cygwin "mounts" (internally) any portion in "acl" mode, which is on by default, a file created under Cygwin has an ACE that denies all access to the NULL SID. This apparently makes UoW utterly unable to read it. If you change the Cygwin mounts to "noacl", the problem is fixed for the future, but all files already created in Cygwin remain inaccessible.

This has nothing to do with writing to the lxss folder.

[johnwcowan]

To reset the problematic ACLs to something UoW can handle, cd in Cygwin or command.exe to a directory containing your Cygwin files, and execute "icacls . /reset /t /c /l /q". This is rather slow, but will fix all existing files.

To make sure there are no problems in future, edit the final line in the /etc/fstab file in Cygwin to say:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
C:\cygwin / ntfs binary,noacl,override 0 0

Shut down all Cygwin processes; this will take effect when you start them again. For 64-bit Cygwin, change the last line from cygwin to cygwin64.

[doctordns]

does resetting the ACLs also fix the problem I reported??

[johnwcowan]

No, because as mentioned above you are trying to do something unsupported: mess around in the lxss directory on the Win32 side. Everything you want to share between UoW and Win32 should be done in /mnt/c space; you can make symlinks on the UoW side to make things look more natural.

[benhillis]

Thanks @johnwcowan, that is correct. Closing this issue out.

[jmenashe]

I am still seeing this issue without cygwin being involved.

Step 1: Create an empty text file at %localappdata%\Lxss\home\<user>\test.txt by right-clicking inside of the folder and selecting New>Text Document
Step 2: Run bash in Windows and change to the home directory with cd ~
Step 3: List all files in the home directory: ls -lha
Step 4: test.txt is not in the output.

Certainly this sort of behavior should be properly supported, right?

[aseering]

@jmenashe -- no, this behavior is explicitly not supported. Access to VolFS (anything underneath %localappdata%\Lxss\) from outside of WSL is not a supported operation. The intent is that you treat that directory as an opaque data store for your Linux installation.

Microsoft's stated reason for this is that most Windows applications don't understand Linux-style metadata and so tend to corrupt the state associated with files, as you're seeing here. I personally agree that simple cases like this could be made to work better. But note that WSL does some additional file buffering for performance that it's unclear that Windows would know about (so Windows apps might not see complete file contents); WSL is going to support things like inotify which tracks when Linux files are edited, whose semantics become clouded when systems other than Linux edit files; etc.

If you want to share files, you can do so from /mnt/c/ or similar on the Linux side. You can make that more convenient by creating symlinks in your home directory that point to your working directories in /mnt/c/.

[libphy]

I have the same issue.
I accessed .md file in the ubuntu bash's /home/username/subfolder/ from Windows using Atom editor. Then I created other new files in the same folder using Atom, I can view, modify in Windows. However when I type 'ls' in bash, those new files don't appear. It is not an issue if the file was created from bash by tying 'touch XXX.md'

[benhillis]

@libphy - https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

[libphy]

Thanks benhillis.

By the way, a quick way around- I created a file xxx.md using bash, then in Atom editor, I copy & pasted from the file (say, yyy.md) I created from Windows. It seems that modification of files (at least .md) are saved using a Windows app (I only tested in Atom- don't know about other apps) properly. I was able to view the file and git push (in bash) the new changes made through Windows Atom.

[benhillis]

As long as you aren't modifying files that are under %localappdata%\lxss you'll be fine. Our guidance is if you will be accessing files from both WSL and Windows processes, to work somewhere out your DrvFs mounts (/mnt/c).

[aseering]

Editing files in Linux /home from Windows isn't really supposed to work, but it will sometimes work as long as your editor is only editing files and not creating new files, and as long as your editor is configured to modify files in place, rather than (as is the default for many editors) implementing "save" as writing a new file and moving it on top of the old file.

[libphy]

I see. Thanks for the explanation. Seems I was lucky that it was modifying in place, not replacing.

[kenchris]

Well that sucks... because I cannot use VSCode from bash to edit things that I checkout using git.

[johnwcowan]

@kenchris: Cygwin is your friend if that's how you want to do things. UoW is for pure-Linux operations, Cygwin is for hybrid operations.

[dethoma]

@kenchris You can also checkout to a /mnt/ DrvFs location that will allow you to interop with Windows programs

[guai]

I somehow got undeleteable file in wsl folder
Can't remove it neither from wsl nor from windows both escalated
Can there at least some repair tool be made?

[doctordns]

There are a couple of reasons why the file appears uneletable. It could be that the file is in use - a reboot might help that. The other is ACL. From the WIndows side, you can try to look at the file's ACL using the GUI, taking ownership if needed and updating the ACL so you can delete it

[AlienKevin]

From my personal experience, I recommend putting your code folder directly inside WSL. Currently, WSL 2 does not detect windows file updates when a command is running. File watchers like Chokidar do not work in WSL 2. Plus, all operations - git commit, git push, git diff, localhost serving, etc. - are all significantly faster when the files are stored in WSL instead of being mounted from Windows. I hope future WSL releases fix the issues of file system sync.

[jeacott1]

this really should be properly fixed. it really is an awful experience as is.

[shutfu]

I created a new folder on an external harddrive called "backup". Q:\backup

in WSL2 if i run the command
ls -a /mnt/q/

the backup folder is not listed. everything else that is in the q:\ directory is listed though.