[WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps

[SteveSandersonMS]

WSL2 is really close to being a perfect runtime environment for server apps being developed in Windows. Great job! One missing feature however is breaking a core part of the developer flow.

For sources stored on the Windows filesystem, any changes made by Windows applications such as Visual Studio do not trigger any file change notifications as far as Linux apps are concerned. This means that all "live rebuild"-type tools don't work (examples: webpack --watch, jekyll --interactive, and Tilt.dev) when running under WSL2. This unfortunately renders many modern dev workflows unviable.

Notes:

• I strongly expect this is already a known issue as hinted here. However I was unable to find any open GitHub issue that specifically tracks this. Unable to save file when inotify is in use (using Node) #1956 is about a different scenario, File contents differs on mounted Windows drive between Windows and WSL #4064 isn't specifically about change notifications, [WSL 2] File watchers like create-react-app, gulp or sass doesn't work #4224 is closed, WSL2 Increase the maximum amount of inotify user watches #4293 doesn't fix it.
• I'm aware the WSL team suggests that with WSL2 it's good to store your application sources inside the Linux filesystem instead of the Windows one. However I don't think that's a viable solution since the whole point of WSL (for me) is to be able to use Windows-based editors such as full VS with a Linux dev environment. If it was sufficient to use Linux-based editors, I'd just use Mac/Linux as my actual OS and would have no need for WSL.
• This did work great on WSL1
• Changing fs.inotify.max_user_watches doesn't affect this, since the issue is about changes originating on the Windows side.

Bug report template

• Your Windows build number: 10.0.19033.1

• What you're doing and what's happening:

  This applies to all tools that listen for file change notifications, but as an example take webpack. Repro steps:

  • In your Windows filesystem, create an empty directory (example: c:\repro), and then add these three files to it
  • In a WSL2 Ubuntu 18.04 environment, install Node and NPM: sudo apt-get install nodejs npm
  • Still in WSL2, go into the directory from earlier: cd /mnt/c/repro
  • Restore NPM dependencies: npm i
  • Run Webpack in watch mode: npm run build:watch. Wait a few seconds until it completes the first build. It will now be waiting for further changes to your source files.
  • In a Windows application (e.g., Notepad or Visual Studio), open c:\repro\index.js and save some change to it. For example, change 'Hello, world' to 'Hello, world 2'.

• What's wrong / what should be happening instead:

  Expected behavior: Webpack should see the change and rebuild. That is, you'll see it log information about another build, and the output in dist/bundle.js will be updated.

  Actual behavior: Webpack doesn't respond at all, because there's no file change notification.

Finally I understand that the fix for this is likely to be "add file watch capabilities to the Plan9 server", and you may feel this is already being tracked by #4064. However #4064 describes a more obscure symptom of this missing feature and makes it sound like an intermittent issue. What I'm reporting here is not intermittent at all, and is a pretty mainstream scenario (using tools like webpack --watch). Thanks!

[therealkenc]

Yes, #4064 is most unfortunately titled. Worse, the OP has no repro steps and an unecessary symlink confusing the direction they are talking about. Craig's notepad.exe repro with cat isn't an inotify(7) (file watcher) problem, even if implementing inotify is the fix to whatever loosly implied sync problems are going on over there.

Nevertheless #4701 got closed as a dupe with (quoth):

We need to add file watch capabilities to the Plan9 server that serves files to a WSL2 distro, and we're tracking that work item here

So, best I can tell, #4064 is being treated as the LZ for inotify triggers from Windows to WSL2. For lack. #4169 is pretty much exactly your use-case also landed dupe #4064.

This did work great on WSL1

Yes, known regress.

[nake89]

Is there a temporary fix to this? This is giving me a headache.

Using Windows 10, WSL 2. Running npm run serve on my Vue project, which normally hot reloads when I do changes (on my Linux and Mac, and WSL1 and I think maybe WSL2 before(?)). Now I have to shut down and restart the Vue server.

Will probably just install Linux on this machine. Developing on a Windows machine is a real pain.

[craigloewen-msft]

@nake89 are you able to move your project over to the Linux root file system? i.e: Store in your Linux home folder for example? Are there any factors that are blocking you from doing so?

And per @therealkenc 's comment this would be a much better landing zone for adding inotify to the 9P file server. I'll update my comment in #4701 to point here, and add some tags to this issue.

[nake89]

@craigloewen-msft Thanks for messaging me back! I actually solved my issue by moving my project to the linux filesystem in WSL and have had no problems so far. I suggest doing the same. In VS Code simply type ctrl-shift-p and then type "Remote-WSL: New Window" This lets users use the linux filesystem in vs code, for those that did not know this :)

[SteveSandersonMS]

@nake89 That's great if your scenario allows it. But just to clarify for anyone else reading, that's not a solution in general as it doesn't work for other Windows-based editors such as VS.

[craigloewen-msft]

@SteveSandersonMS agreed, we will still be tracking this issue here. :)

[ghost]

Hi, I am encountering this with docker-sync. My setup is:

• working folder under C:\users for various php projects
• Edit a file in phpstorm
• Changes reflected within my WSL2 Ubuntu instance
• Running docker containers within WSL2 with volumes synced using docker-sync and Unison

If I make a change to a file directly inside Ubuntu, changes are reflected in the container's mounted volume. However, if I edit a file in PhpStorm in Windows, the change is reflected in Ubuntu as expected but not in the container.

I can't easily move my files to the Linux filesystem because I need to use PhpStorm and other Windows tools in my dev environment, and I also have other stuff such as Google drive sync running to back up local changes. So the workaround doesn't work for me.

[Carl-Hugo]

@craigloewen-msft Thanks for messaging me back! I actually solved my issue by moving my project to the linux filesystem in WSL and have had no problems so far. I suggest doing the same. In VS Code simply type ctrl-shift-p and then type "Remote-WSL: New Window" This lets users use the linux filesystem in vs code, for those that did not know this :)

This is a great workaround that will save me lots of time until WSL2 supports this use-case. Thanks for sharing!

[Carl-Hugo]

@craigloewen-msft Thanks for messaging me back! I actually solved my issue by moving my project to the linux filesystem in WSL and have had no problems so far. I suggest doing the same. In VS Code simply type ctrl-shift-p and then type "Remote-WSL: New Window" This lets users use the linux filesystem in vs code, for those that did not know this :)

This is a great workaround that will save me lots of time until WSL2 supports this use-case. Thanks for sharing!

I wrote a small blog post explaining this workaround and talking about a few more things that I discovered/experienced, using Jekyll on WSL2: Speed up your builds to up to 375% and watch for changes for an even faster dev cycle using this workaround on WSL2/Ubuntu, if that can help someone.

Note: that applies to more than just Jekyll, Jekyll it was just the catalyst.

[safizn]

For those stumbling upon, some notes about WSL2 features & limitations (OS build 19041.21, insiders slow ring):

• inotify filesystem events are not propagated between WSL2 & Windows. Although it will be supported in future releases as stated in Microsoft documentation.
• Accessing Windows filesystem from WSL2, when developing is extremely slow. While moving projects to WSL2 filesystem, will increase performance, much faster than WSL1 & Windows development. (WSL2 can be accessed in path \\wsl$\)
• VSCode installed in Windows, with remote extension pack, will install VSCode server automatically in WSL2. Some extensions should be installed in the WSL2 side to work, when openning files from the local WSL2 filesystem. The VSCode Extenions tab in the UI provides indications and guides through the required changes.
• localhost is managed for you by Windows, and allows access to WSL2. Some cases require accessing the WSL2 VM by it's IP directly.
• Symlinks in WSL2 work seamlessly between WSL2, Docker containers, & Windows, which wasn't the case with WSL1. Using Docker Desktop on WSL2 experimental feature.
• Some graphical programs (e.g. SmartGit/GitKraken) need to be installed in WSL2 and accessed through GUI client through Windows (Unix X server), to overcome the inotify events & performance degredations.

[ivellios]

While I am having similar issue with my React App and I am looking for a solution to this as well, I can reply to:

I can't easily move my files to the Linux filesystem because I need to use PhpStorm and other Windows tools in my dev environment, and I also have other stuff such as Google drive sync running to back up local changes. So the workaround doesn't work for me.
@weknowsoftware

@nake89 That's great if your scenario allows it. But just to clarify for anyone else reading, that's not a solution in general as it doesn't work for other Windows-based editors such as VS.
@SteveSandersonMS

This hint by @myuseringithub:

• Accessing Windows filesystem from WSL2, when developing is extremely slow. While moving projects to WSL2 filesystem, will increase performance, much faster than WSL1 & Windows development. (WSL2 can be accessed in path \\wsl$\)

is a great one to help you! Also I found out yesterday that since \\wsl$\ is a network resource in Windows you can easily map it to a drive. Then in ANY editor/tool you can use it as if it was on your computer. Just go to the Explorer and manually enter this address to access the resource. You will most likely see "Ubuntu" folder. It is a root of your WSL and it can be mapped to the drive (right click -> map to drive). That helped me setup my project on WSL natively, while being able to edit in the windows editor.

Though now I am struggling with Docker containers permissions, which I hope to solve separately and see if reloads in my app work.

Hope that helps.

[nicks]

Is there anything that app devs can do to workaround this in their apps? e.g., is there a different file-change notification API that would work on WSL2 across filesystems? (there are a lot of different file-change notification APIs). Or should we wait patiently for inotify support?

[Carl-Hugo]

Is there anything that app devs can do to workaround this in their apps? e.g., is there a different file-change notification API that would work on WSL2 across filesystems? (there are a lot of different file-change notification APIs). Or should we wait patiently for inotify support?

You can use the Linux file system directly, accessible from Windows too; see #4739 (comment)

[mattlacey]

@Carl-Hugo Does that work for you, as in, are changed detected? I've been using the \wsl$ path with windows editors for a while because with WSL2 the Linux FS is so much faster, but even when using windows editors with files stored there it's not triggering HMR when using npm watch.

[Carl-Hugo]

@mattlacey Yes it works...

1. 
2. ctrl+s the README.md file in VS Code (Windows)
3. 

Side note: for-the-new-order is not a sect but a Star Wars RPG thing 😉

[vielhuber]

Some graphical programs (e.g. SmartGit/GitKraken) need to be installed in WSL2 and accessed through GUI client through Windows (Unix X server), to overcome the inotify events & performance degredations.

Can you please elaborate on that: Is this working well? Any tutorials / starting points how to set this up?

[safizn]

@vielhuber I wrote it as a comment for myself, tried to implement it once without success. Just wait till WSL2 will support inotify. You could still use graphical interfaces for git, only that you would have to constantly refresh to see changes, which is the same case when dealing with VSCode's git panel.

But if you wish to dig deeper, check out:

I wrote these comments when setting up my development environment

• Setup Linux graphical server and Windows client to access WSL2 graphical programs: https://medium.com/@chuckdries/installing-gitkraken-in-wsl-2-15bf6459f823 https://wiki.ubuntu.com/WSL#Running_Graphical_Applications
• Install smartGit graphical program in WSL2 and access it through Windows to take advantage of inotify support for autorefresh (as not yet supported), and use wsl own git installation.
• (follow steps of above link) Install X server e.g. VcXsrv, symlink configs (from this repo's resource folder), set firewall protocol to allow WSL2 own ip access.
• smartgit for linux https://www.syntevo.com/smartgit/download/#installation-instructions

[vielhuber]

@myuseringithub Awesome thank you.

[huysentruitw]

I use my regular Git client in Windows, because my project is still on my Windows machine. However, to get livereload working, I simply add a symlink from my WSL2 home directory to the project on my windows machine, f.e.:

ln -s /mnt/d/projects/contrib/create-your-future-website/ ~/create-your-future-website

After that, I start jekyll serve --livereload from ~/create-your-future-website and open that folder in VS code using ctrl-shift-p and then type "Remote-WSL: New Window" as explained above.

This way, you don't have to move your project and can still enjoy your favorite git client in Windows. Profit!

[huysentruitw]

Arg, scratch the above idea. It only seems to get triggered by file changes at the top-level directory. 😢

[helgatheviking]

Lol . I did move on to pure Ubuntu

[jankap]

We started to use the WSL filesystem as recommended. Clone into \\wsl$\ubuntu. From windows and open either that path in Windows tools or work inside WSL, or even better in devcontainers. It's pretty fast.

[raffaeler]

@jankap the problem here is not the speed but getting the file system changes notification from an app runing under linux.

[jankap]

@jankap the problem here is not the speed but getting the file system changes notification from an app runing under linux.

You get the notifications in Linux that way. The other way round could be problematic. I think the question is where the notifications and native speeds have to be available. Windows? Use window FS. Linux or docker based devcontainers? Use Linux FS which can initially be accessed via the network share to clone the code etc.

Nevertheless, this issue should be fixed. I'm not saying there is none.

[dig12345]

I tried to work around this by setting up a windows file share and mounting with cifs-utils. I was able to mount it however there seems to be some strange bug with running windows executables from the wsl command line within a folder on the mount. If I run ping.exe outside of the mount subfolder it works. Inside a subfolder within the mount I get the following cryptic output: /mnt/c/windows/system32/ping.exe: Invalid argument . Here is the mount command I am using mount -t cifs -o username=linux_user,password='pass',vers=3.0 //192.168.0.100/code_linux /mnt/smb/code. The only clue I have is that the issue only happens when you are at least 1 folder deep inside the mount. At the root of the mount, windows executables work fine.

If I can resolve this execution issue, I think SMB would be a decent workaround until inotify gets fixed....

PS The reason /mnt/c fix is important, is that storing files on linux is risky since WSL distros have a tendency to spontaneously lose all user files. It also means files can persist across distro changes etc..

[Fleker]

I just ran into this problem this evening when spinning up a new Angular project after updating my default to WSL2. Thankfully I still have the original and jumped back to run the project with live reload.

[potchy]

We started to use the WSL filesystem as recommended. Clone into \\wsl$\ubuntu. From windows and open either that path in Windows tools or work inside WSL, or even better in devcontainers. It's pretty fast.

I ended up doing this as well.
It's kinda awkward at first, but it's the path of least resistance and it works great once you get used to it.
If you don't want to setup .gitconfig again, just include it in /home/{your Linux user here}/.gitconfig like so.

[include]
	path = /mnt/c/Users/{your Windows user here}/.gitconfig

[jrhager84]

Dang - Still no movement? Unfortunate.

[jonstrutz11]

I came here because VS Code would not automatically refresh source control upon file changes since I have all my project files stored in the windows filesystem - specifically, so I can have them backed up via OneDrive.

I found a solution where you can store your project files on the Linux filesystem and then regularly sync them to your windows filesystem OneDrive folder so that they get backed up. See this blog post from Stephen Rees-Carter for details on how to set it up.

(fyi I deleted the mysql database backup part of the script he provides - I just used it to sync files to a folder in my OneDrive and used Task Scheduler to have it run daily)

Not perfect and takes an hour or two to set up the first time, but after that you don't need to worry about it and it seems to work quite well so far.

[kiweezi]

It's annoying that this still isn't fixed and the fact there is no communication from the team is pretty bad.

What seemed to work for me was creating a devcontainer and then using the Clone Respository in Container Volume... function in vscode with the devcontainers extension. Makes git run much faster, plus you don't have to worry about setting up your environment in WSL etc.

Devcontainers are relatively easy to setup, you just need WSL and Docker installed. The vscode extension for devcontainers can help you create a devcontainer configuration file really quickly.

Not sure if this has been said before, but hopefully it helps someone.

[sdserage]

Is this ever going to get fixed? If not, you should at least close it as wontfix so that people can move on with their lives (probably to Linux).

If only that was an option, my company is working on Windows exclusively and my coworkers are more likely to pull their own teeth out before switching off of Windows.

Is there really no progress for this issue still?

[PedramMarandi]

This has been open since 2019 with no official response.

[PaulOst]

"[WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps #4739"

Is there a fix for this anywhere in our future? If you're never going to fix this, then say so!

[ManfredLange]

Perhaps, not fixing it is a subtle message from Microsoft that we all should move to Linux proper ... ? If we did, this problem would certainly be resolved. 🤔

[mindplay-dk]

Can someone lock this thread, please? Getting tired of "me too" notifications, and it's fairly clear the maintainers aren't going to respond, so you might as well block this noise and just let us know if it ever gets fixed.

Or if you're not going to address this, maybe just close the thread.

Everyone knows what the problem is, and only MS can solve it - no reason to waste anybody else's time then.

[dig12345]

Can someone lock this thread, please? Getting tired of "me too" notifications, and it's fairly clear the maintainers aren't going to respond, so you might as well block this noise and just let us know if it ever gets fixed.

Or if you're not going to address this, maybe just close the thread.

Everyone knows what the problem is, and only MS can solve it - no reason to waste anybody else's time then.

Umm click unsubscribe? Me too comments demonstrate how widespread the issue is and allow for discussion around workarounds/root cause. If you're not interested, simply unsubscribe.

[jankap]

This has been open since 2019 with no official response.

I'm curious, did anybody ever addressed this to MS engineers directly? Are they aware of that?

[jankap]

Another comment: Notifications work when using volume mounts, not bind mounts. This can be very helpful for build folders:

https://code.visualstudio.com/remote/advancedcontainers/improve-performance#_use-a-targeted-named-volume

[raffaeler]

Another comment: Notifications work when using volume mounts, not bind mounts. This can be very helpful for build folders:

https://code.visualstudio.com/remote/advancedcontainers/improve-performance#_use-a-targeted-named-volume

My main scenario is when you want to keep in sync windows and linux folders with rsync.
Did you test this scenario?

[omt66]

Can someone lock this thread, please? Getting tired of "me too" notifications, and it's fairly clear the maintainers aren't going to respond, so you might as well block this noise and just let us know if it ever gets fixed.
Or if you're not going to address this, maybe just close the thread.
Everyone knows what the problem is, and only MS can solve it - no reason to waste anybody else's time then.

Umm click unsubscribe? Me too comments demonstrate how widespread the issue is and allow for discussion around workarounds/root cause. If you're not interested, simply unsubscribe.

Ditto. This is a big problem, if anyone doesn't want to hear, they should unsubscribe!