File-system events not correctly propagating from host to container

Expected behavior

When a change is made to a file in a shared volume on the host, the WRITE and CHMOD events should propagate to the container

Actual behavior

The CHMOD and WRITE events happen in the host, but only the CHMOD event propagates

Information

When modifying handlers.go in the host

Host output:

[info] fsnotify event: "./handlers.go": CHMOD
[info] fsnotify event: "./handlers.go": WRITE

Container output:

[info] fsnotify event: "./handlers.go": CHMOD

System information

$ pinata diagnose -u
OS X: version 10.11.4 (build: 15E65)
Docker.app: version: v1.11.1-beta14.5.m
Running diagnostic tests:
[OK]      docker-cli
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x

Steps to reproduce the behavior

  1. Create a container with a shared volume
  2. Modify a file from the host
  3. Observe file-system events in host and container

Same problem here, you’re not alone.

I’m using a React/Redux app, which uses webpack (watching file notifications for build). Hopefully they can address this in the next beta :confused:

I could’ve sworn this was working a couple of weeks ago, but just tried again today and have the same issue.

Hi,

We need some more information about exactly what you are running on the host and in the container to capture the inotify events. Could you provide a minimal reproduction case?

Thanks,

David

Hi David,

I had the same issue and reduced it to the following setup:

  • OS X 10.10.5 (14F1808)
  • Docker for Mac 1.12.0-rc2-beta17 (build: 9779)
  • Docker version 1.12.0-rc2, build 906eacd, experimental
  • docker-compose version 1.8.0-rc1, build 9bf6bc6

With the following files:

~/docker-test/Dockerfile

FROM debian:jessie
RUN apt-get update && apt-get install -y inotify-tools
CMD echo "hello" && sleep 99999

~/docker-test/docker-compose.yaml

version: '2'
services:
    test:
        build: .
        volumes:
            - "~/docker-test/dir:/var/test"
            - "~/docker-test/dir/file.txt:/etc/foo.txt"

~/docker-test/dir/file.txt

test

Executing the these commands:

cd ~/docker-test
docker-compose up -d --build
docker-compose exec test bash
# Then inside the container:
inotifywait -rme modify,attrib,move,close_write,create,delete,delete_self /var/test

The container prints Watches established. and I execute in another session on the host:

touch ~/docker-test/dir/test.txt
echo "foo" > ~/docker-test/dir/test.txt

After that, the running inotifywait command in the container should show the created file, but it doesn’t.

If I remove the /etc/foo.txt volume from the docker-compose.yaml and execute the same commands, the events work correctly and the container prints:

/var/test/ CREATE test.txt
/var/test/ CREATE test.txt
/var/test/ ATTRIB test.txt
/var/test/ MODIFY test.txt

I was not able to reduce it more than that, e.g. doing the same with docker run instead of docker-compose doesn’t show the bug.

Seeing this still … however I’m not getting any events to propagate to my container but have a very complicated volume structure.

Beta 21.1 has been released which should resolve this issue. Thanks for your report and reproduction and for participating in the Docker for Mac Beta!

1 Like

I was having the same issue trying to do Rails development on Mac OS X version 10.11.6 (15G31) using Guard to watch my project for changes and run my tests. I just downloaded and installed the latest Docker for Mac build (1.12.0-beta21 [build 11019]) and can confirm that this issue appears to be resolved. Wahoo!

I’m still seeing issues, in particular with file renames. Everything else works nicely, just if I do a rename on a file on the host machine in the volume mounted in the container, the operation does not propagate to the container. :frowning:

I’m also seeing an issue with renames

The lack of rename events is a documented limitation. See https://docs.docker.com/docker-for-mac/osxfs/#/file-system-events where they are called “Move events”.

We should likely send at the very least modification events for both parties of the rename but we currently ignore renames. This causes problems for triggering computation based on file edition with TextEdit for instance which uses rename to safely save files.

I’m curious, @m4olivei and @justafish, what are your use cases for rename events?

Thanks @dsheets, good to know. The use case for rename ops would include code refactoring. Where I ran into it is in a Drupal project. I renamed a service class, which didn’t get propagated, and then updates a services.yml file to point to the new name, which did get propagated, and the site broke b/c it couldn’t find the new class.

What code is being used to watch for the file system changes? Does it require specifically an IN_RENAME event or could it work with something else? Any examples or pointers you can provide would be helpful.

Rename event support is tricky because OS X’s FSEvents framework does not send the source and target of renames unlike Linux. In OS X, two events for the source and target files are generated both of which are marked as rename events. There is no means, as far as I know, to disambiguate these events from other potentially concurrent rename events. There are some half-way solutions we could implement that would trigger modification events or creation/deletion events but accurately sending rename events may be ultimately impossible without a change to OS X.

Sorry wasn’t completely understanding our setup. We have a mounted volume for our web dir at /var/www/mirror, and then we use unison to copy that over to /var/www/html where the web server is pointed at. As I understand it the lack of the fsevents for rename means that unison doesn’t pick up the change in the mounted volume, and doesn’t propagate the rename into /var/www/html

@dsheets I have the same setup as @m4olivei , so I have that same issue. However this also isn’t working for me in a normal mounted volume when watching a group of files to recompile if something is renamed e.g. Sass, JavaScript etc

this would solve both my use cases - it doesn’t have to specifically be rename

Beta 24 released last week now triggers either a DELETE event or a MODIFY event for files participating in rename operations depending on whether they exist (or not) when the event is received. I hope this addresses your use case and please let us know if you continue to experience issues.

Thanks for participating in the Docker for Mac Beta!

Best regards,

David