diff --git a/man7/inotify.7 b/man7/inotify.7 index 4ac26d05e..af4de6c83 100644 --- a/man7/inotify.7 +++ b/man7/inotify.7 @@ -635,13 +635,65 @@ For example, it may be necessary to rebuild part or all of the application cache. (One simple, but possibly expensive, approach is to close the inotify file descriptor, empty the cache, -create a new inotify file descriuptor, +create a new inotify file descriptor, and then re-create watches and cache entries for the objects to be monitored.) The inotify API identifies affected files by filename. However, by the time an application processes an inotify event, the filename may already have been deleted or renamed. +.SS Dealing with rename() events +The +.B IN_MOVED_FROM +and +.B IN_MOVED_TO +events that are generated by +.BR rename (2) +are usually available as consecutive events when reading +from the inotify file descriptor. +However, this is not guaranteed. +If multiple processes are triggering events for monitored objects, +then (on rare occasions) an arbitrary number of +other events may appear between the +.B IN_MOVED_FROM +and +.B IN_MOVED_TO +events. + +Matching up the +.B IN_MOVED_FROM +and +.B IN_MOVED_TO +event pair generated by +.BR rename (2) +is thus inherently racy. +(Don't forget that if an object is renamed outside of a monitored directory, +there may not even be an +.BR IN_MOVED_TO +event.) +Heuristic approaches (e.g., assume the events are always consecutive) +can be used to ensure a match in most cases, +but will inevitably miss some cases, +causing the application to perceive the +.B IN_MOVED_FROM +and +.B IN_MOVED_TO +events as being unrelated. +If watch descriptors are destroyed and re-created as a result, +then those watch descriptors will be inconsistent with +the watch descriptors in any pending events. +(Rebuilding the cache and re-creating the inotify file descriptor may +be useful to deal with this scenario.) + +Applications should also allow for the possibility that the +.B IN_MOVED_FROM +event was the last event that could fit in the buffer +returned by the current call to +.BR read (2), +and the accompanying +.B IN_MOVED_TO +event might be fetched only on the next +.BR read (2). .SH BUGS .\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321 .\" implies that unmount events were buggy 2.6.11 to 2.6.36