linux-kernel - Recognizing Inotify move events in pairs.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CABg07fsLytFfv1G1O4tGEx9+g+RXKFcxqsiDvnQFiQS2mwCESg@mail.gmail.com>
Date:	Thu, 12 Apr 2012 11:10:50 +0200
From:	Axel Kittenberger <axkibe@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Recognizing 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
event?

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