Le mardi 26 janvier 2010 à 21:36 +0100, Marc Lehmann a écrit : > On Tue, Jan 26, 2010 at 07:53:18PM +0100, Yoann Vandoorselaere > <[email protected]> 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 code. 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 copy. > > > 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 http://www.prelude-ids.com _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
