[lkml]   [2012]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRecognizing Inotify move events in pairs.
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

Kind regards, Axel

 \ /
  Last update: 2012-04-12 11:15    [W:0.029 / U:3.204 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site