IN_MODIFY launched 2 times for every file about pyinotify

[bdkearns]

You can't hope for such a simple solution-- editors write files in different ways.

http://inotify.aiken.cz/?section=inotify&page=faq&lang=en

Q: What is the difference between IN_MODIFY and IN_CLOSE_WRITE?
The IN_MODIFY event is emitted on a file content change (e.g. via the write() syscall) while IN_CLOSE_WRITE occurs on closing the changed file. It means each change operation causes one IN_MODIFY event (it may occur many times during manipulations with an open file) whereas IN_CLOSE_WRITE is emitted only once (on closing the file).
Q: I write to a file using fprintf() and it doesn't emit IN_MODIFY in some cases. Where is the problem?
Library functions like fprintf() use memory buffers and they needn't always accomplish a syscall to do a real writing to a file. If the real write is not called no IN_MODIFY is emitted. You can force the writing e.g. by calling fflush() but it will negatively affect program performance if done often.
Q: Is it better to use IN_MODIFY or IN_CLOSE_WRITE?
It varies from case to case. Usually it is more suitable to use IN_CLOSE_WRITE because if emitted the all changes on the appropriate file are safely written inside the file. The IN_MODIFY event needn't mean that a file change is finished (data may remain in memory buffers in the application). On the other hand, many logs and similar files must be monitored using IN_MODIFY - in such cases where these files are permanently open and thus no IN_CLOSE_WRITE can be emitted.
Q: Why doesn't work IN_MODIFY nor IN_CLOSE_WRITE on my file?
There is probably a program which doesn't save changes directly into the original file. It creates a temporary file instead, saves data into it and after closing it renames the file to the name of the original one. It is safer but complicates monitoring. The exact mechanism of working with files must be investigated (tools like strace can be useful) and the monitoring setup must be tailored to it.

[seb-m]

Can you reproduce this problem for instance when using the echo command?

$ echo "test1" > /tmp/test
$ echo "test2" >> /tmp/test

[endorama]

No, with echo I got only one event fired...

But with Sublime Text 2, Vim, Nano I always have double event. With gEdit
this does not happen. Now, this seems to be a issue related to the editor
used, but maybe you're able to help me in solving it...

I'm going to hook some cpu expensive task on file modification, and this
differences between editor could really lead to some problems :(

[seb-m]

@endorama as @bdkearns rightfully replied events are application dependents. There are even editors writing to temporary files and then overwriting the destination file whenever a save command is issued. So I'm afraid there is not a unique answer to your problem, I think you have to understand how your target editor works under what you want to observe and kind of find an heuristic that will permit you to take the actions you want.

[endorama]

So actually the only way I can follow is detect which editor is run and monitor the files accordingly!

Thank you all for explanation, there were really useful! :)