Watch descriptor IDs are returned by inotify_add_watch. When calling inotify_rm_watch an IN_IGNORE is placed on the inotify queue pointing to the ID of the removed watch. inotify_add_watch should not return a watch descriptor ID for which events are still on the queue but should return an unused ID. Unfortunately the existing Kernel code does not provide such a guarantee. Actually in rare cases watch descriptor IDs are returned by inotify_add_watch for which events are still on the inotify queue. cf. https://bugzilla.kernel.org/show_bug.cgi?id=77111 Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx> --- man7/inotify.7 | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/man7/inotify.7 b/man7/inotify.7 index 1fc83f8..b1c2f6f 100644 --- a/man7/inotify.7 +++ b/man7/inotify.7 @@ -728,6 +728,18 @@ and the accompanying event might be fetched only on the next .BR read (2). .SH BUGS +As of Linux 3.14, +the following bug exists: +.IP * 3 +.\" FIXME https://bugzilla.kernel.org/show_bug.cgi?id=77111 +.BR inotify_add_watch (2) +may return a watch descriptor ID released by a prior call to +.BR inotify_rm_watch (2) +even if events for this watch descriptor still exist on the inotify queue. +As a workaround the inotify file descriptor can be read until the queue is +empty before calling +.BR inotify_add_watch (2). +.PP .\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321 .\" implies that unmount events were buggy 2.6.11 to 2.6.36 .\" @@ -745,7 +757,7 @@ However, as an unintended effect of other changes, since Linux 2.6.36, an .B IN_IGNORED event is generated in this case. - +.PP Before kernel 2.6.25, .\" commit 1c17d18e3775485bf1e0ce79575eb637a94494a2 the kernel code that was intended to coalesce successive identical events -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
