denoland/deno

Deno.watchFs is not working in WSL environment

aaronwlee opened this issue · 9 comments

aaronwlee commented

Deno.watchFs is not working in WSL(Ubuntu 18.04 LTS Bionic) environment.
Literally, there are no event messages after changing any files.

Spoonbender commented

@aaronwlee please specify which version of Windows you are using, as it didn't always have support for these events (see https://devblogs.microsoft.com/commandline/wsl-adds-inotify-filesystem-change-notification-support/ )

aaronwlee commented

@Spoonbender I'm using Windows 10 19041.388 OS build and using wsl2.

what I'm claiming that it was working with the previous version.

Leokuma commented

Probably related: notify-rs/notify#254

I believe that problem affects deno run --watch too.

Running Deno inside Docker on Windows with WSL2 enabled, deno run --watch never detects any file changes even if I enter the container and change the file from inside the container (Alpine Linux in my case). If I change my Docker settings not to use WSL2, it works perfectly.

  • 👍4
BMogetta commented

same problem here 02/june/2022

twome commented

Same here:

  • Win 10 x64 build 19044.1766
  • WSL2; Ubuntu

Inside WSL2, touching a watched file reliably triggers watchFs, whereas inside Windows, saving a file stored on a Windows/NTFS drive that is mounted into WSL (e.g. as /mnt/g/somefile.js) never triggers watchFs.

0xpr03 commented

saving a file stored on a Windows/NTFS drive that is mounted into WSL (e.g. as /mnt/g/somefile.js) never triggers watchFs

This won't work* as long as you don't want to add a workaround by either switching to a polling-based change detection, through some sort of flag, or detecting WSL2 and then using the workaround. Notify simply won't receive file-events for windows-owned files inside WSL2.

*or wait for WSL2 to maybe fix that problem

twome commented

@0xpr03 yeah I assumed as much. watchFs should be changed to detect WSL (might be good to do this earlier/higher up within Deno anyway, setting a user-visible flag) & then either (a) give an error message explaining this issue, or (b) fall back to polling. The silent failure's no bueno.

0xpr03 commented

I'm thinking about adding some runtime-detection based fallback to notify. This could also contain a WSL detection. But truth be told: If you want "performance", don't use the pollwatcher, if you want full compatibility, use it. So either way it is a trade-off.

Kyiro commented

You can use WSL 1 as a workaround for this issue

  • 👎1