I’ve found the issue, with some help from this answer on a similar post from 2019:
Also a few related links:
opened 11:43AM - 13 Aug 20 UTC
upstream
system:windows
This was originally a comment on [an issue with Revise.jl](https://github.com/ti… mholy/Revise.jl/issues/514), but Tim Holy recommended filing this as a Julia bug, so this is what I'm doing now.
It seems `FileWatching` has problems with [WSL2](https://docs.microsoft.com/en-us/windows/wsl/wsl2-index). Below is what I can reproduce. The gist of it seems to be that `FileWatching` works within the "native" file system of WSL, but ceases to work in the normal Windows file system. (One funny thing is that it makes a slight difference if the file is modified from a WSL program - but only if you watch the directory it's in. That's the last working case below.)
julia> using FileWatching
julia> watch_file("/tmp/")
# change /tmp/foo from WSL bash
FileWatching.FileEvent(false, true, false)
julia> watch_file("/tmp/foo")
# change /tmp/foo from WSL bash
FileWatching.FileEvent(false, true, false)
julia> watch_file("/tmp/")
# change /tmp/foo from Windows-Emacs
FileWatching.FileEvent(false, true, false)
julia> watch_file("/tmp/foo")
# change /tmp/foo from Windows-Emacs
FileWatching.FileEvent(false, true, false)
julia> watch_file("/mnt/c/Users/edi/Desktop")
# change c:/Users/edi/Desktop/foo from WSL bash
FileWatching.FileEvent(false, true, false)
julia> watch_file("/mnt/c/Users/edi/Desktop/foo")
# change c:/Users/edi/Desktop/foo from WSL bash
# NOTHING HAPPENS
julia> watch_file("/mnt/c/Users/edi/Desktop")
# change c:/Users/edi/Desktop/foo from Windows-Emacs
# NOTHING HAPPENS
julia> watch_file("/mnt/c/Users/edi/Desktop/foo")
# change c:/Users/edi/Desktop/foo from Windows-Emacs
# NOTHING HAPPENS
julia> versioninfo()
Julia Version 1.4.2
Commit 44fa15b150* (2020-05-23 18:35 UTC)
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-8.0.1 (ORCJIT, skylake)
opened 04:10PM - 21 Jun 23 UTC
closed 04:29PM - 21 Jun 23 UTC
Here is a MWE:
```Dockerfile
FROM julia:1.9.1
WORKDIR /mwe
CMD ["julia", "--… project=.", "-e", "using FileWatching; println(watch_folder(\"in\"))"]
```
Run the container
```ps
docker run -it -v c:\my_folder:/mwe/in mwe
```
and then drop a file into `c:\my_folder`. Nothing happens.
If you do
```ps
docker run -it -v c:\my_folder:/mwe/in mwe bash
```
and then navigate to `/mwe/in`, you will see the file.
So it seems that the events are not being propagated through the mounted volume.
The same works if the docker container is built and run on a linux host.
Also using this function on Windows natively works fine.
This behavior is not unexpected according to the docs [here](https://docs.julialang.org/en/v1/stdlib/FileWatching/#FileWatching.watch_folder), c.f. [the node.js docs here](https://nodejs.org/api/fs.html#fs_caveats), but maybe a work-around could be provided.
opened 02:55PM - 06 Dec 19 UTC
feature
wsl2
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](https://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](https://github.com/microsoft/WSL/issues/1956#issuecomment-491266167). However I was unable to find any open GitHub issue that specifically tracks this. #1956 is about a different scenario, #4064 isn't specifically about change notifications, #4224 is closed, #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](https://gist.github.com/SteveSandersonMS/b6e1e2db31ba12fd0c7ae288dc61660f)
* 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!
Basically, Revise relies on getting notified when files change, but that doesn’t work properly inside a Docker container, for files which are actually on the Windows host machine and accessed via a bind volume mount inside the container.
I found two workarounds:
Use the Revise polling mode by setting JULIA_REVISE_POLL=1 in the environment before loading Revise. This checks files every several seconds for changes, and it does work although it’s frustrating to have to wait.
Use Revise within the container only for files within the “native” Unix filesystem, not files mounted from the host system. E.g. clone the package repo into the home directory inside the container and just work there. Revise works perfectly with that setup. The only downside is you can’t quickly work with the same filetree in the host system, but in practice that’s not an issue.
Hope this helps someone else who comes across the same issue!
2 Likes