-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps #4739
Comments
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 Nevertheless #4701 got closed as a dupe with (quoth):
So, best I can tell, #4064 is being treated as the LZ for
Yes, known regress. |
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. |
@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. |
@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 :) |
@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 agreed, we will still be tracking this issue here. :) |
Hi, I am encountering this with docker-sync. My setup is:
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. |
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. |
For those stumbling upon, some notes about WSL2 features & limitations (OS build 19041.21, insiders slow ring):
|
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:
This hint by @myuseringithub:
is a great one to help you! Also I found out yesterday that since 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. |
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) |
@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. |
@mattlacey Yes it works... Side note: |
Can you please elaborate on that: Is this working well? Any tutorials / starting points how to set this up? |
@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:
|
@myuseringithub Awesome thank you. |
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.:
After that, I start This way, you don't have to move your project and can still enjoy your favorite git client in Windows. Profit! |
Arg, scratch the above idea. It only seems to get triggered by file changes at the top-level directory. 😢 |
I also desperately need this feature |
Can you run your project inside WSL? That fixes issues like this for me. If you need access from Windows just use |
accessing is not enough, the need is to use rsync to keep the files updated (aka file system notification). Anyway, on my side I don't care anymore as I moved my dev machine to Ubuntu and resolved this issue radically. The best surprise from this move, was discovering the file system operations on Ubuntu are hugely faster during C++/.NET compile time or nodjs development. |
That works but it defeats interoperability. Didn't they say that WSL is interoperable with Windows? |
Not sure what you mean by that. You keep your projects in WSL file system, access them via And if you want to take things one step further you can (on top of WSL) setup your project to use VSCode "Dev Containers" in order to run the project & VSCode in virtual Linux distro of your choosing. Which not only makes it easier to run Linux primary projects on Windows as you can just run the linux commands natively for the project, improves WSL disk compatibility when the whole setup is doing native linux filesystem calls, and it also separates project dependencies of you main system. As in you can run whichever version of Node.js, Python for each project dev container without any conflicts with versions installed on your host OS. That way if project x recommends Debian, Python 3.10, Cmake 3.8 or whatever - no problem, just configure your devcontainer with those dependencies and you are good to go. |
@MiikaH sorry, this is totally irrelevant. Could we please stay on topic and focus on the bug in WSL? |
Discussing workarounds for the bug is the only relevant use for this topic, so that people who are affected can find a working solution for their use case. Especially when it is clear that we may have to wait decade or two until Microsoft actually fixes the bug itself. |
You can't call "don't use X feature" a workaround for an issue titled "feature X does not work". The issue is "File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps". |
Nothing works :( I've tried the /mnt/... version it doesn't work. I've also tried the linux filesystem:
So currently WSL2 is useles for webpack development. :( |
I found a pretty ugly workaround some time ago. Since the pain of this issue seems never to end I want to share it. In my development docker image I added the "Unison file synchronizer", supervisor and scripts. The code for nodejs development is here: https://github.com/bridgefield/docker-node-dev The solution is far from being perfect. It takes much performance because unison can not use ionotify. |
@WaldemarH maybe it's better to delete your not-so-relevant comments on this bug? This is a bug report about WSL2 file system change notifications, not a samba tutorial. |
This comment has been minimized.
This comment has been minimized.
@rw3iss So should I put it back on? .. I know I would be happy if somebody gave me at least some working option. |
@WaldemarH Yeah... would suggest just summarizing it a bit as you did, as an alternative solution, and then maybe linking to a gist with full instructions. Doesn't hurt and someone else may find it useful for sure. AFAIK it's one of the only ways to actually link them via network operations. |
This is still an issue. I have to use Will this ever be solved? We aren't talking about a solo maintainer here, but Microsoft. |
My team and I have completed our migration to NextJS. About a dozen apps.
No issues with HMR since.
…On Thu, Jun 6, 2024, 6:59 AM Valentino Stillhardt ***@***.***> wrote:
This is still an issue.
I have to use usePolling: true with vite to get it working, but this eats
60% of my CPU and just makes everything sluggish.
Will this ever be solved? We aren't talking about a solo maintainer here,
but *Microsoft*.
—
Reply to this email directly, view it on GitHub
<#4739 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AK77FPBD3X37QYQBJ36U2S3ZGBMMPAVCNFSM4JWZQM4KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJVGIZTONBVGIZA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
In the meantime I found a workaround using the Vite:
It's now a lot faster, but it's also just a workaround, not a fix. Hope to see this fixed someday. |
Is there a way for Angular to use polling in its CLI? The most recent versions of Node and Angular no longer work on the |
now "docker compose up --build" spins up a development build locally, hot reloading on Windows 11 + Docker Desktop didn't work, but that may be Windows + WSL2 specific setup problem, see the following: - vercel/next.js#36774 - microsoft/WSL#4739 also: - remove deprecated version number from docker-compose.yml refs PT-1792
now "docker compose up --build" spins up a development build locally, hot reloading on Windows 11 + Docker Desktop didn't work, but that may be Windows + WSL2 specific setup problem, see the following: - vercel/next.js#36774 - microsoft/WSL#4739 also: - remove deprecated version number from docker-compose.yml refs PT-1792
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:
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:c:\repro
), and then add these three files to itsudo apt-get install nodejs npm
cd /mnt/c/repro
npm i
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.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!The text was updated successfully, but these errors were encountered: