Le mardi 26 janvier 2010 à 16:23 +0100, Marc Lehmann a écrit : > On Tue, Jan 26, 2010 at 09:40:19AM +0100, Yoann Vandoorselaere > <[email protected]> wrote: > > As I understand it, inotify guarantee that you'll get an event for every > > changes on the file. > > That is impossible unless you make everything synchronous, so inotify > cannot guarantee it.
Again, as I understand it, Inotify events are generated at syscall levels, so they are synchronous to a syscall. >From the Inotify manpage: "If successive output inotify events produced on the inotify file descriptor are identical (same wd, mask, cookie, and name) then they are coalesced into a single event if the older event has not yet been read (but see BUGS)." For the record, the Linux auditing subsystem rely on Inotify. [...] > > This is not a problem if there is no more event queued for the given wd; > > but in the other case, if there are multiple events queued, then the > > infy_cb loop is going to continue calling infy_wd() with the *old* watch > > descriptor. > > That doesn't matter, as we have the new watcher in place, so no events > will be lost (modulo kernel bugs). > > i.e. even if there is a bug in inotify causing atcual events for the old > id, we will receive the same events for the new id (again, barring bugs in > the kernel). If inotify already reported the event, I don't think it will update the WD associated with it. Theses event are already stored in the userspace buffer declared by libev, and you cannot expect the Kernel to update the WD associated with event that you have already read(). infy_cb() loop through the events, and call infy_wd(), which will sucessfuly lookup the first event. However, since libev registered WD is changed at this point, the second iteration of infy_wd() won't find the correct ev_stat handler. [...] > > > libev needs to rearm inotify after a change, as the event might have > > > changed the path. > > > > Are you talking about file renaming/deletion?s > > Yes. > > > If you are, I might have some suggestion on other way to handle that. > > Sure, I don't see any - afaics you have to change watchers. At best you > can make an optimisation for certain events, but changing is required in > general, as the path changes. It would be interesting for libev to provide the ability to keep monitoring the file until no application reference it anymore (st_nlink). In Prelude-LML we would like to handle deletion the following way: If the file has been deleted but is still referenced by others applications, then continue monitoring it, and open a new ev_stat() handler in case any application re-create the filesystem file. -- 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
