Updates of files outside the container are not visible inside of it

[andreasRulle]

• I have tried with the latest version of my channel (Stable or Edge)
• I have uploaded Diagnostics
• Diagnostics ID: DBB125A1-AA56-44DD-8B43-6B2A7FA5895B/20200616125432

Expected behavior

When a file in a mounted directory is changed on the Windows file system it is expected that the change becomes visible to the file as it is seen in the linux container.

Actual behavior

The change in the file is almost never visible from within the container.
To continue to develop with the present Docker-Desktop-Version after each (!) change in the code basis the command

docker-compose restart supplierportal.local

has to be issued to make the code change effective within the container.

Information

Please, help us understand the problem. For instance:

• Is it reproducible?
  Yes, almost each time a file is changed in the IDE the content and the timestamp of the file is not changed in the container.
• Is the problem new?
  Yes, under 2.1.X the current mountings worked in team of several developers for more than a half of a year without any problem.
• Did the problem appear with an update?
  Yes, it appeared after migrating to version 2.3.0.3 (45519)
• Windows Version: Funktionsupdate für Windows 10, Version 1909, KB4497165: Microcodeupdates von Intel
• Docker Desktop Version: 2.3.0.3 (45519)
• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM:
  No.

The update problem exists for directories the are linked by

new-item -itemtype junction

and for those do not have these links.

The flag consistent is used for the volume mounts:

volumes:
- ./supplier_cloud:/home/sportal/lieferantenportalsource:consistent

Sorry to report that the problem is still there, at least on my machine.

With best regards,

Andreas

[InfamousStarFox]

I have the same problem in docker 2.3.0.3 (45519).

Command used:
docker run -it --rm -v ${PWD}:/srv/ mycontainer

When editing a file in the host, the corresponding file in the mounted volume is not updated.

This issue is the same as unresolved issue #5530

[InfamousStarFox]

After doing some more digging, it looks like it may not be a problem caused by docker, but by WSL2.

The reason this issue appears in 2.3.0.3 but not 2.1.X is the added reliance upon WSL2 that was added in the newer edition. The issue comes from Windows not passing inotify to WSL2.

See:

• [WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps microsoft/WSL#4739
• Filesystem watchers like libinotify do not work microsoft/WSL#216

One fix would be to bypass the inotify issue by hosting the code within a linux filesystem such as \wsl${dist}\

However, docker does not currently allow for mounting network locations, so this will not work.

See: #5888

[davclark]

@InfamousStarFox you can mount WSL2 filesystems in a docker container if you run the docker command from the WSL2 distro. You can even do this from Powershell by using the wsl CLI. I put an example here: #4812 (comment)

Does that help? Once you've enabled WSL2, Windows filesystem performance is even worse than on Hyper-V, but mounting from WSL2 distros is fast! I just did some comparisons for the gigantum blog.

[slominskir]

After doing some more digging, it looks like it may not be a problem caused by docker, but by WSL2.

I had this problem without WSL enabled (Hyper-V enabled instead). Was using Docker 2.3.0.3. I actually jumped through all the hoops to upgrade Windows 10 to the 2004 version so that I could install WSL2 hoping that it would fix this issue (it didn't of course).

Looks like Windows bind mounts were broken while refactoring code the last few releases (probably in anticipation of WSL 2) as seen here #5530

See: #5888

That issue is closed now. Looks like automated close bot got it...

So it looks like the workarounds are (ordered with increasing horribleness):

• rollback to Docker 2.1.0.5
• docker-compose restart after each file change
• put your code inside a WSL VM and then launch docker from within the VM and edit your files from within the VM (and you can use a hack like a VSCode plugin to edit files inside the VM from outside)

[docker-robott]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked