| fanotify issues in 2.6.34-rc6-next-20100506 | Anders Blomdell | 5/7/10 2:40 AM | I have started to have a look at the fanotify system, based on information gleaned from: [1] http://people.redhat.com/~eparis/fanotify/ Unfortunately there seems to be some bug in the current implemenation, since --- fanotify.c.orig 2010-03-27 05:26:27.000000000 +0100 // fanotify_init(flags, event_f_flags, priority) seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch' /dir/to/watch/a: pid=18584 open A similar program using inotify gets all events correctly.
mkdir /dir/not/watched What is the rationale for not reporting link/unlink events via fanotify? Best regards Anders Blomdell -- |
| Re: fanotify issues in 2.6.34-rc6-next-20100506 | Eric Paris | 5/7/10 6:30 AM | On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote: > seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch' I'm looking at it right now, not sure what's going on, probably screwed
|
| Re: fanotify issues in 2.6.34-rc6-next-20100506 | Eric Paris | 5/7/10 10:00 AM | On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote: > seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch' sometimes I'm not the sharpest knife in the drawer. switch statements diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
|
| Re: fanotify issues in 2.6.34-rc6-next-20100506 | JohnG | 6/3/12 7:00 PM | > On Fri, 2010-05-07 at 11:24 +0200, Anders Blomdell wrote:> ... switch statements are hard. Two years passed, but this patch was never applied and fanotify is as broken as it has been. So, two questions: - does anyone going to finally apply that patch (add "break" before case (FSNOTIFY_EVENT_NONE) in should_merge) - what is the status of fanotify? Does anybody still use it? Does it work (aside from this bug?) Just in case, I copied that old patch below:
|