ev_stat inotify implementation might miss events

Yoann Vandoorselaere yoann.v at prelude-ids.com
Wed Jan 27 11:18:18 CET 2010

Le mardi 26 janvier 2010 à 21:36 +0100, Marc Lehmann a écrit :
> On Tue, Jan 26, 2010 at 07:53:18PM +0100, Yoann Vandoorselaere <yoann.v at prelude-ids.com> wrote:
> > > Again, your understanding is flawed - that would be a security bug :)
> > 
> > After looking at Linux kernel 2.6.32 kernel code, I can confirm that my
> > understanding is not flawed. 
> it is :/
> > I guess you then need to explain why this is a security bug ;)
> > static inline void fsnotify_modify(struct dentry *dentry)
>                    ^^^^^^^^^^
> I told you you are confusing fsnotify with inotify.
> fsnotify gives you an event for each change, and is synchronous. inotify
> does not and is asynchronous. fsnotify is usable for auditing, inotify much
> less so. fsnotify requires privileges, inotify does not.

The point of the kernel code I copied in my previous mail was to show
you that the system directly call fsnotify, which itself ping inotify.

Again, Inotify can merge events of the same type together. Inotify
guarantee to provide a notification for any event on a file (but there
might be only one notification for 10 event of the same type).

> > > That would be a kernel bug - when I ask the kernel to give me events for a
> > > specific path, and it doesn't give me them, that's a bug in the kernel.
> > 
> > It does. The problem is that libev read a pile of Inotify events, but
> > every events in the pile, except the first one will get ignored.
> I have no clue what you are talking about, this is simply not what libev
> does.
> When it registers an inotify watcher for a file, it expects to get events for
> this file _after_ it has registered.
> And this is what happens.
> Your problem is that you fail to understand inotify - it simply cnanot
> give you one event for each change, this is impossible without it becoming
> synchronous, introducing a security bug.

Marc, why don't you listen ? The original subject of this conversation
is not Inotify, but rather that libev has a problem where it sometime
won't call the application callback when Inotify has notified a change.

Instead of concentrating on the problem, you keep routing the discussion
in a void technical conversation where you insist that libev has no bug.

I can confirm this issue, I have it here and can reproduce it reliably.
I confirm Inotify send the notification, and that libev ignore it (for
reason I already described in earlier mails).

I'm trying to help improve your project by escalating bugs. Libev is
great, but like any software, it might happen that a bug is found in the

If you have no interest in that, or you react by insulting people, then
it is no problem for me to fix the bug for myself and maintain my own

> > > Libev needs to stay portable.
> > 
> > The behavior described in my previous mail can be emulated with stat(),
> > and is fully portable, as per POSIX specification:
> Grr. Claims, claims, claims, all wrong.
> > "Unless otherwise specified, the structure members st_mode, st_ino,
> Point being? How do I magically find the new name of the file?

My previous explanation was confusing, so let me rephrase: I was talking
about a way to keep monitoring files that have been moved (and not
deleted, as I previously mentioned).

You can do this with or without Inotify support.

In order to emulate that (no inotify), you may provide a function so
that an application can _optionally_ provides libev with a file
descriptor used to access the file. 

Then you can use the internal libev timer to poll the file and continue
monitoring it until fstat() return an st_nlink of 0.

This doesn't provide a way to get the new filename when Inotify support
is not enabled, but this provides a way to keep monitoring files that
are moved around, for application that have an open FD referencing them.

[skipping the pile of insults over here]

Yoann Vandoorselaere | Directeur Technique/CTO | PreludeIDS Technologies
Tel: +33 (0)1 40 24 65 10                      Fax: +33 (0)1 40 24 65 28

More information about the libev mailing list