[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.023 / U:10.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site