From: Anders Blomdell <anders.blomdell@control.lth.se>
To: Eric Paris <eparis@parisplace.org>, linux-kernel@vger.kernel.org
Subject: fanotify issues in 2.6.34-rc6-next-20100506
Date: Fri, 07 May 2010 11:24:48 +0200 [thread overview]
Message-ID: <4BE3DC60.7080105@control.lth.se> (raw)
I have started to have a look at the fanotify system, based on information
gleaned from:
[1] http://people.redhat.com/~eparis/fanotify/
[2] http://lwn.net/Articles/360955/
Unfortunately there seems to be some bug in the current implemenation, since
running a patched version of the fanotify.c application found in [1]
--- fanotify.c.orig 2010-03-27 05:26:27.000000000 +0100
+++ fanotify.c 2010-05-07 10:56:38.000000000 +0200
@@ -125,7 +125,7 @@
fan_mask |= FAN_ALL_PERM_EVENTS;
// fanotify_init(flags, event_f_flags, priority)
- fan_fd = fanotify_init(0, O_RDONLY | O_LARGEFILE, 0);
+ fan_fd = fanotify_init(0, 0, 0);
if (fan_fd < 0)
goto fail;
seems to lose/corrupt events. For instance running 'fanotify -c /dir/to/watch'
and then running the command 'cd /dir/to/watch ; touch a b c d e f g h i j k l'
might generate (results are more or less random):
/dir/to/watch/a: pid=18584 open
/dir/to/watch/a: pid=18584 close(writable)
/dir/to/watch/b: pid=18584 open # 2 open events for b
/dir/to/watch/b: pid=18584 open close(writable) #
/dir/to/watch/d: pid=18584 open # events for c missing
/dir/to/watch/d: pid=18584 open close(writable) # 2 open events for d
/dir/to/watch/f: pid=18584 open close(writable) # events for e missing
/dir/to/watch/g: pid=18584 open close(writable)
/dir/to/watch/h: pid=18584 open close(writable)
/dir/to/watch/i: pid=18584 open close(writable)
/dir/to/watch/j: pid=18584 open
/dir/to/watch/j: pid=18584 close(writable)
/dir/to/watch/k: pid=18584 open
/dir/to/watch/k: pid=18584 open close(writable) # 2 open events for k
/dir/to/watch/l: pid=18584 close(writable) # no open event for l
A similar program using inotify gets all events correctly.
I have also problems with the fact that the following sequence dosn't leave a
trace in the fanotify events:
mkdir /dir/not/watched
touch /dir/not/watched/z
ln /dir/not/watched/z /dir/to/watch/z
rm /dir/not/watched/z
rmdir /dir/not/watched)
What is the rationale for not reporting link/unlink events via fanotify?
Best regards
Anders Blomdell
--
Anders Blomdell Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
next reply other threads:[~2010-05-07 9:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 9:24 Anders Blomdell [this message]
2010-05-07 13:21 ` fanotify issues in 2.6.34-rc6-next-20100506 Eric Paris
2010-05-07 16:57 ` Eric Paris
2012-06-04 1:49 ` JohnG
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE3DC60.7080105@control.lth.se \
--to=anders.blomdell@control.lth.se \
--cc=eparis@parisplace.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox