inotifywait gets just 'ATTRIB'

[hamann]

I set up a vagrant vm with your vagrant notify-forwarder plugin, host is a Mac OS X (10.10.5), guest is debian jessie. In the vm there's an app running, waiting for some fs events by calling inotifywait => https://github.com/synrc/fs/blob/master/src/sys/inotifywait.erl#L10
If I open/edit some file on the host nothing happens (should compile something).
I played a bit, started inotifywait /vagrant and edited, deleted, created files, but all I can see is

vagrant@db24-phoenix /vagrant ❯❯❯ while true; do inotifywait /vagrant -r; done                                                               
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ ATTRIB mix.exs
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ ATTRIB mix.exs
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ ATTRIB mix.lock
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/script/ ATTRIB .vagrant_provision.sh.swp
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/.git/ ATTRIB FETCH_HEAD
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/.git/ ATTRIB FETCH_HEAD
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.

If I do something inside the vm in /vagrant inotifywait shows

Watches established.
/vagrant/ ATTRIB,ISDIR test
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ CREATE foo
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ DELETE foo
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/vagrant/ ATTRIB foo

So what's happening here? Is notify-forwarder not able to forward the correct event types?

There's another app running (https://github.com/brunch/brunch), which responds to events from notify-forwarder, but I did not dig deeper since it's doing its job ;)

[hamann]

inotifywatch also just shows 'attrib' after editing a file

vagrant@db24-phoenix /vagrant ❯❯❯ inotifywatch /vagrant -v -r
Establishing watches...
Setting up watch(es) on /vagrant
OK, /vagrant is now being watched.
Total of 665 watches.
Finished establishing watches, now collecting statistics.
^Ctotal  attrib  filename
1      1       /vagrant/script/

[mhallin]

This is unfortunately a limitation of the simple way I simulate events - the file is just touched with a new mtime. notify-forwarder is more of a tool that forwards that some file event has happened, rather than the specific event.

I guess a few of the other events could be properly forwarded, but CREATE/DELETE would be hard to simulate without injecting events directly into the kernel, which would probably require a kernel module. If anyone know of a simpler way to inject inotify events, please let me know. :-)

[jchook]

Thanks for the explanation @mhallin.

We should probably mention this front-and-center on the README.md as right now it reads as though the proper event will be forwarded.

A simple tool for forwarding file system notifications from one host to another, possibly remapping the path in the process. Useful when running a reloading build system on one machine and editing files on another, or over shared folders to a VM.

Many reloading build systems will not respond to attrib events without adjusting their parameters.

For example, use iwatch -e attrib to respond to attrib events with iwatch. Some software such as entr do not support this at all.

[christhomas]

I modified my fork of this project to read a byte from the file and write it back in the exact same place and same file, so this triggers CLOSEWAIT and for me this fixed. I know it causes more filesystem activity but it does fix the problem for me. So I'm willing to accept the hit.