The below patch lets userspace have more control over the inodes that
inotify will watch. It introduces two new flags.
IN_ONLYDIR -- only watch the inode if it is a directory.
This is needed to avoid the race that can occur when we want to be
sure that we are watching a directory.
IN_DONT_FOLLOW -- don't follow a symlink. In combination
with IN_ONLYDIR we can make sure that we don't watch the target of
symlinks.
The issues the flags fix came up when writing the gnome-vfs inotify
backend. Default behaviour is unchanged.
Signed-off-by: John McCutchan <[email protected]>
Acked-by: Robert Love <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
People have run into a problem when they do this:
watch (file1, all_events);
watch (file2, some_events);
if file2 is a hard link to file1, some events will be missed because by
default we replace the mask. The patch below adds a flag IN_MASK_ADD which
will cause inotify to add to the existing mask if present.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Robert Love <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Bypass an inotify-related fastpath spinlock and several function calls on
systems which have no inotify watches registered.
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
There is an off by one problem with idr_get_new_above.
The comment and function name suggest that it will return an id >
starting_id, but it actually returned an id >= starting_id, and kernel
callers other than inotify treated it as such.
The patch below fixes the comment, and fixes inotifys usage. The
function name still doesn't match the behaviour, but it never did.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The patch below unhooks fsnotify from vfs_unlink & vfs_rmdir. It
introduces two new fsnotify calls, that are hooked in at the dcache
level. This not only more closely matches how the VFS layer works, it
also avoids the problem with locking and inode lifetimes.
The two functions are
- fsnotify_nameremove -- called when a directory entry is going away.
It notifies the PARENT of the deletion. This is called from
d_delete().
- inoderemove -- called when the files inode itself is going away. It
notifies the inode that is being deleted. This is called from
dentry_iput().
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This avoids the whole #ifdef mess by just getting a copy of
dentry->d_inode before d_delete is called - that makes the codepaths the
same for the INOTIFY/DNOTIFY cases as for the regular no-notify case.
I've been running this under a Gnome session for the last 10 minutes.
Inotify is being used extensively.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The included patch fixes a problem where a inotify client would receive a
delete event before the file was actually deleted. The bug affects both
dnotify & inotify.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Robert Love <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
When you rm a watch, an IN_IGNORED event is sent down the event queue
with the watch descriptor that you just rm'd.
If you then add a watch you could get the ignored watch's wd and if you
haven't read the entire event queue, user space will think that it's
newly created watch was just ignored.
To avoid this problem we just use idr_get_new_above instead of
idr_get_new.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Robert Love <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
When a file is moved over an existing file that you are watching,
inotify won't send you a DELETE_SELF event and it won't unref the inode
until the inotify instance is closed by the application.
Signed-off-by: John McCutchan <[email protected]>
Signed-off-by: Robert Love <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
John McCutchan