From: Eric Paris <eparis@redhat.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Matt Helsley <matthltc@us.ibm.com>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
Michael Kerrisk <michael.kerrisk@gmail.com>
Subject: Re: [GIT PULL] notification tree: directory events
Date: Wed, 18 Aug 2010 11:59:06 -0400 [thread overview]
Message-ID: <1282147146.21419.165.camel@acb20005.ipt.aol.com> (raw)
In-Reply-To: <201008181747.15461.agruen@suse.de>
On Wed, 2010-08-18 at 17:47 +0200, Andreas Gruenbacher wrote:
> Eric,
>
> one more thing that doesn't make sense is events on directories: when watching
> a directory, some actions like reading a directory or creat()ing a file in the
> directory will generate events (even open_perm and access_perm), but other
> actions like hard linking files into the directory or removing files will not
> create any events. This means that fanotify currently cannot be used for
> watching for directory changes.
>
> In my opinion, events on directories should either be made to actually work,
> or else no directory events at all should be generated.
>
> Also, I can think of users of fanotify which are not concerned with directory
> events at all. It would make sense to allow such users to subscribe only to
> file events and not receive any directory events which they will end up
> ignoring anyway.
>
> Again it shows that this code just wasn't ready to be merged yet ...
I'm going to file your e-mail into my todo list and hopefully I get the
time to look at the ability to ignore directory events. Nothing hard
about it. It's as easy as defining a flag and adding a conditional in
the code but it's not high on my list.
Thus far your e-mails have pointed out one bug in the permissions
implementation I am currently working fixing and a bunch of complaining
about features you can imagine someone might someday want but which
noone has actually stood up and said 'I will use this' or 'this sucks
for my use case'. I can find all sorts of things around the kernel
where I can imagine some mythical users might want to do something
different but it isn't a reason to prevent merger. I'd love to have
more review, I'm certainly going to look at your wish list, but don't
expect response to future trolling messages.
-Eric
next prev parent reply other threads:[~2010-08-18 15:59 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 15:58 [GIT PULL] notification tree - try 37! Eric Paris
2010-08-06 23:34 ` Matt Helsley
2010-08-07 0:06 ` Christoph Hellwig
2010-08-07 19:15 ` Eric Paris
2010-08-07 20:55 ` Matt Helsley
2010-08-16 20:32 ` Andreas Gruenbacher
2010-08-17 3:39 ` Eric Paris
2010-08-17 4:03 ` Matt Helsley
2010-08-17 8:09 ` Andreas Gruenbacher
2010-08-17 15:08 ` Eric Paris
2010-08-19 20:24 ` Andreas Gruenbacher
2010-08-19 20:32 ` Andreas Gruenbacher
2010-08-19 20:42 ` Eric Paris
2010-08-19 21:07 ` Andreas Gruenbacher
2010-08-19 21:22 ` Andreas Gruenbacher
2010-08-20 3:50 ` Eric Paris
2010-08-20 12:38 ` Andreas Gruenbacher
2010-08-23 16:46 ` Eric Paris
2010-08-23 22:38 ` Andreas Gruenbacher
2010-08-20 0:00 ` Andreas Gruenbacher
2010-08-17 8:38 ` Andreas Gruenbacher
2010-08-17 15:24 ` Eric Paris
2010-08-17 15:48 ` Andreas Gruenbacher
2010-08-18 14:18 ` Andreas Gruenbacher
2010-08-17 9:45 ` Tvrtko Ursulin
2010-08-17 10:01 ` Andreas Gruenbacher
2010-08-17 10:12 ` Tvrtko Ursulin
2010-08-17 10:55 ` Tvrtko Ursulin
2010-08-17 15:27 ` Eric Paris
2010-08-18 15:47 ` [GIT PULL] notification tree: directory events Andreas Gruenbacher
2010-08-18 15:59 ` Eric Paris [this message]
2010-08-18 16:42 ` Christoph Hellwig
2010-08-18 17:07 ` Eric Paris
2010-08-19 12:44 ` Andreas Gruenbacher
2010-08-19 15:00 ` Eric Paris
2010-08-19 23:41 ` Andreas Gruenbacher
2010-08-20 3:38 ` Eric Paris
2010-08-20 5:19 ` Andreas Dilger
2010-08-20 9:21 ` Christoph Hellwig
2010-08-20 15:29 ` Andreas Gruenbacher
2010-08-20 20:39 ` Andreas Dilger
2010-08-20 9:09 ` Tvrtko Ursulin
2010-08-20 11:07 ` Andreas Gruenbacher
2010-08-20 11:25 ` Andreas Gruenbacher
2010-08-20 12:16 ` Andreas Gruenbacher
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=1282147146.21419.165.camel@acb20005.ipt.aol.com \
--to=eparis@redhat.com \
--cc=agruen@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=michael.kerrisk@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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
Powered by JetHome