diff --git a/man7/inotify.7 b/man7/inotify.7
index 60bde571b..c0e3e0a48 100644
--- a/man7/inotify.7
+++ b/man7/inotify.7
@@ -601,6 +601,17 @@ The
 returns the number of bytes available to read from an
 inotify file descriptor.
 .SS Limitations and caveats
+The inotify API provides no information about the user or process that
+triggered the inotify event.
+In particular, there is no easy
+way for a process that is monitoring events via inotify
+to distinguish events that it triggers
+itself from those that are triggered by other processes.
+
+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.
+
 The inotify API identifies events via watch descriptors.
 It is the application's responsibility to cache a mapping
 (if one is needed) between watch descriptors and pathnames.
@@ -620,13 +631,6 @@ Therefore, you may want to scan the contents of the subdirectory
 immediately after adding the watch (and, if desired,
 recursively add watches for any subdirectories that it contains).
 
-The inotify API provides no information about the user or process that
-triggered the inotify event.
-In particular, there is no easy
-way for a process that is monitoring events via inotify
-to distinguish events that it triggers
-itself from those that are triggered by other processes.
-
 Note that the event queue can overflow.
 In this case, events are lost.
 Robust applications should handle the possibility of
@@ -638,10 +642,6 @@ approach is to close the inotify file descriptor, empty the cache,
 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