Recognizing Inotify move events in pairs.

From: Axel Kittenberger
Date: Thu Apr 12 2012 - 05:11:37 EST


Dear LKML,

I got a problem pairing inotify MOVE_FROM and MOVE_TO events. The
basic problem is, so far I assumed when the read from the inotify fd
return 0. "Nothing more", and I got a MOVE_FROM event where no
matching MOVE_TO has yet arrived, that it will not arrive, since the
file/directory has been moved outside of the directory tree I'm
watching. This has worked great for two years. However, recently I
keep getting complains from my users using kernel >= 3.0 that my
application ( Lsyncd ) does not recognize move events correctly and
assumes a move to be a file delete and a file creation instead. From
the debug logs I received the events happened like this.

* reading a MOVE_FROM from the inotify fd with cookie = 815
* reading from inotify fd returns 0 --> no more events.
--> My daemon concludes the file has been moved to somewhere it does
not watch, and behaves as it would have been deleted.
* the great pselect() fires! more events on the inotify fd.
* reading a MOVE_TO from the inotify fd with cookie = 815
--> Oops, the daemon behaved already, like it would have been a delete.

So, was I wrong in my naive assumption that when a move happens the
two inotify events will always come in one queue before the kernel
reports the queue is empty? Is there a correct way to know from a
MOVE_FROM that no matching MOVE_TO will arrive before the next inotify
event arrive (which might take a long time)? Is that actually even a
proven assumption that the matching MOVE_TO event will be the next
event?

Kind regards, Axel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/