mirror of https://github.com/mkerrisk/man-pages
inotify.7: Add text on dealing with rename() events
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
a79d28b202
commit
85e179c5c2
|
@ -635,13 +635,65 @@ For example, it may be necessary to rebuild part or all of
|
||||||
the application cache.
|
the application cache.
|
||||||
(One simple, but possibly expensive,
|
(One simple, but possibly expensive,
|
||||||
approach is to close the inotify file descriptor, empty the cache,
|
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
|
and then re-create watches and cache entries
|
||||||
for the objects to be monitored.)
|
for the objects to be monitored.)
|
||||||
|
|
||||||
The inotify API identifies affected files by filename.
|
The inotify API identifies affected files by filename.
|
||||||
However, by the time an application processes an inotify event,
|
However, by the time an application processes an inotify event,
|
||||||
the filename may already have been deleted or renamed.
|
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
|
.SH BUGS
|
||||||
.\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
|
.\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
|
||||||
.\" implies that unmount events were buggy 2.6.11 to 2.6.36
|
.\" implies that unmount events were buggy 2.6.11 to 2.6.36
|
||||||
|
|
Loading…
Reference in New Issue