4 events on file change

[notify-rs]

4 events on file change

[passcod]

What are you using to change the file? Does a simple touch trigger this, or is this a program (which may have its own weird behaviour)?

[azerupi]

Thanks for the fast reply! :)

I was using Atom to change the files, just modifying and saving. I will try with touch and let you know if that changed anything.

[blaenk]

Yeah, oftentimes editors and programs have their own ways of saving/writing files, like they might save to a separate file and then rename it to the target file. For example, vim and emacs don't simply just write to the file directly from what I've observed. You'll notice touch by itself does do what you expect. You'll have to accommodate the way atom does it yourself.

Although it is indeed weird that you're receiving 4 writes to the same file for every write you say you make? Were you only printing out the write events, or were other events being triggered?

[azerupi]

Ah ok, thanks for the clarification!
In that case I will close the issue and keep my workaround :)
Thanks!

[blaenk]

No need to close it if what I said ended up not applying to your situation, since I can't be sure. It does seem weird that atom is creating that many write events, but then I'm not sure how atom works. One thing you can do to check though is like @passcod said, try using touch on the file and you should see what you expect, a single event. That will rule out your code being the problem; I doubt your code is the problem.

Honestly recursing like you are in your workaround doesn't seem very sound. I think it's creating separate "inotify instances" so basically you get one event, you process it, then you create another inotify instance which means you start with a fresh "event queue" which is why you don't "get" the repeated events. I think a better approach would avoid recreating inotify instances (i.e. notify::Watcher::new) and instead introduce perhaps some sort of debouncing logic to ignore repeated events within a certain short timespan, or something.

[azerupi]

I will just re-open if there is indeed a bug.

Honestly recursing like you are in your workaround doesn't seem very sound.

I know, what I am most afraid of is to hit the max recursion limit.. I should probably try to find a more clever solution like you said.

instead introduce perhaps some sort of debouncing logic to ignore repeated events within a certain short timespan

I agree, this would be a more robust solution. I am not sure however this would be trivial to implement in my case, because the action I do after a file changed takes a little time (± 1s). And as I understand it, the events are queued in the receiver until processed. So the time I would measure would not be the time between the events but the time it took the action to complete...
I tried to find a way to empty the receiver rx, to clear all the events that happened while doing the task, but I didn't find any method for that in the std docs. Seems kind of weird that you can't flush it.

Do you have a solution?

[passcod]

Maybe just recv the events and then immediately discard them if you're processing the action? I do something similar in cargo-watch (which was the original reason for notify to exist).