Watcher is triggered but container not notified

[BernCarney]

I got everything setup and have the watcher running in verbose mode to debug. It correctly recognizes containers and when I update a file in a volume, it's shown in the watcher output. It says it's notifying the container but the file change actions that are expected (hugo server) are never run. Seems like it can read container information fine but has trouble sending information back.

[merofeev]

Hi @BernCarney , Could you please try the following:

1. Start your container (don't start docker-volume-watcher at all!)
2. then from powershell or cmd docker exec NAME_OF_YOUR_CONTAINER touch PATH_TO_FILE_THAT_SHOULD_TRIGGER_YOUR_SERVER_UPDATE
3. then check if this action triggered actions you expect from your server.

[BernCarney]

So, I tested a few things and here were my findings:

1. First off, I stripped down my image to the bare bones to try and rule out some things.
2. Created a container with no entrypoint to ensure sh -c was used
3. from powershell I ran docker exec -it NAME_OF_CONTAINER ls -a path/to/file to be sure the container was being mounted correctly
4. from powershell I ran docker exec -it NAME_OF_CONTAINER touch path/to/file which ran without errors no server trigger
5. from powershell I ran docker exec -it NAME_OF_CONTAINER echo 'text here' >> path/to/file which ran without errors and correctly appended text here to the file no server trigger
6. from powershell I ran docker exec -it NAME_OF_CONTAINER sh which ran without errors and brought me to /src # where I then ran echo 'text' >> path/to/file which correctly appended text to the end of the file and triggered the server correctly

From what I can gather if you open a shell in the container, things operate as normal, however, if you run docker exec commands, which should function the same, they do not trigger a file change correctly. Possibly a permissions thing but I have no idea since docker exec correctly appends text which I would believe would fail if permissions were wrong. Output of ls -ahe of the file in question:

[merofeev]

Could you please also try running touch from sh?

Please note that >> in docker exec -it NAME_OF_CONTAINER echo 'text here' >> path/to/file was probably parsed by powershell, thus the write to file was (probably) done by Windows-host (instead of container).

[BernCarney]

I’ll work on it more when I’m home from work in a few hours and update you. On Fri, Nov 3, 2017 at 3:20 PM Mikhail Erofeev notifications@github.com wrote:

Could you please also try running touch from sh?

Please note that >> in docker exec -it NAME_OF_CONTAINER echo 'text here'

path/to/file was probably parsed by powershell, thus the write to file was (probably) done by Windows-host (instead of container).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/merofeev/docker-windows-volume-watcher/issues/4#issuecomment-341830220, or mute the thread https://github.com/notifications/unsubscribe-auth/ARl6mnn-2-g6P5iWyXli9HT15N1M56urks5sy4ORgaJpZM4QQln0 .

[BernCarney]

You were correct, powershell was parsing echo before sending to the container. docker exec -it NAME_OF_CONTAINER sh -c "echo 'text here' >> path/to/file was executed without errors and triggered the server correctly.

touch worked correctly in sh but never triggered the server to update:

[merofeev]

Thank you for sending details. I have done some expirements with Hugo server. I confirm that the Hugo server doesn't react to file changes caused by touch and chmod (which is used by docker-volume-watcher).

To investigate this issue further I looked into Hugo source code (see line 848 and block of comments above it). As we can see Hugo explicitly ignores chmod events.

To check, if touch events are ignored as well I started hugo server with verbose output option --verbose. Then I executed touch content/posts/p.md. This caused new line in the server output to appear INFO 2017/11/04 12:54:44 Received System Events: ["********/site/content/posts/p.md": CHMOD] but hasn't triggered site rebuild. This means that touch events are recognized by Hugo as chmod events and thus are ignored.

All in all this means that docker-volume-watcher can't trigger Hugo site rebuild (since Hugo explicitly ignores chmod events). Moreover, I don't know any reasonable workaround for this issue. As extreme solution you can try rebuilding Hugo with lines 848-850 removed, if this helps you can try asking Hugo developers to implement the new command line argument that will enable chmod events handling.

[BernCarney]

I appreciate you looking into this. The only workaround I could see would be to truncate the file by 1 but I think that would get messy. Another possible option would be use a host OS function to append a value at the end of the file then use a Linux function to then remove that character and trigger the event.

Either way, I don’t think it’s an issue on your end I’ll submit a feature request with Hugo to add a flag to allow chmod events to cause a server update.

Thanks!