[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110823092150.366d8899@notabene.brown>
Date: Tue, 23 Aug 2011 09:21:50 +1000
From: NeilBrown <neilb@...e.de>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: Jamie Lokier <jamie@...reable.org>,
Al Viro <viro@...IV.linux.org.uk>,
Sylvain Rochet <gradator@...dator.net>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-nfs@...r.kernel.org
Subject: Re: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing
On Mon, 22 Aug 2011 13:22:39 -0400 "J. Bruce Fields" <bfields@...ldses.org>
wrote:
> On Mon, Aug 22, 2011 at 09:07:51AM +1000, NeilBrown wrote:
> > One is to use bind mounts. i.e. I effectively do
> > mount --bind $HOME/.config $HOME/.config
> > and ask for events from the newly created vfsmnt.
> > This will not catch changes made through file descriptors that were opened
> > before I did the mount, or through hard links from some other directory
> > tree. But for a particular use-case that might not be a problem.
>
> I'm missing what the extra vfsmount gets you here. The problems seem
> just the same as if you don't have one.
>
> Oh, wait, I see, it's that the file descriptors are associated with
> vfsmounts, not just dentries. Hm.
"Hm" might be right. writes have a 'struct file', but mkdir and rename etc
just get an inode.
So to be able to notify based on vfsmnt, mkdirat - for examine - would need
to pass the path to vfs_mkdir rather than path.dentry->d_inode, and vfs_mkdir
would have to pass that path to fsnotify_mkdir. So more intrusive that I
imagined, but still quite do-able.... if it were thought to be useful.
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists