LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

inotify.7: Add text on dealing with rename() events 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-04-02 14:02:44 +02:00
parent a79d28b202
commit 85e179c5c2
1 changed files with 53 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
man7/inotify.7
View File

@ -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