When you add multiple file watches in the same directory while files are being modified, the events that you receive are inconsistent due to races in the code. This is because the package attempts to optimize usage of the limited number of watch handles by only watching directories, but filtering events based on files when they are received. Because of this, code like this will produce inconsistent results:
fsmon.AddWatch("foo1", h1)
createFile("foo")
fsmon.AddWatch("foo", h)
modifyFile("foo")
Sometimes theCreated() method on h will get called, sometimes not. Modified() will always get called. This is because the inotify notifications are pushed to applications asynchronously, so sometimes the IN_CREATE event will be received before the handler has been registered, and sometimes it will be received after (despite happening before).
I have a test for this in the test suite, but neglected to push it because it causes the tests to hang.
The only reliable fix for this issue seems to be either a) changing the API somehow, or b) removing these optimizations (or making them optional; users can disable them if it becomes an issue)
When you add multiple file watches in the same directory while files are being modified, the events that you receive are inconsistent due to races in the code. This is because the package attempts to optimize usage of the limited number of watch handles by only watching directories, but filtering events based on files when they are received. Because of this, code like this will produce inconsistent results:
Sometimes the
Created()method onhwill get called, sometimes not.Modified()will always get called. This is because the inotify notifications are pushed to applications asynchronously, so sometimes the IN_CREATE event will be received before the handler has been registered, and sometimes it will be received after (despite happening before).I have a test for this in the test suite, but neglected to push it because it causes the tests to hang.
The only reliable fix for this issue seems to be either a) changing the API somehow, or b) removing these optimizations (or making them optional; users can disable them if it becomes an issue)