Inotify write visibility guarantees

Question

I'm confused if there are some ordering guarantees when working with inotify. For example:

 Process1
    |
    |
write(fd, void *, 8192)
    |
    |
    v
some.file ------- IN_MODIFY -------> Process2

Is it guaranteed that when Process2 receives IN_MODIFY event all 8192 written by Process1 will be available for reading by the Process2?

For a better understanding it would be nice to have the link where you read about that ordering guarantee or may be even quote the relevant part. — Robert, Jun 15 '20 at 21:05
@Robert This is what the question, actually. Is there some ordering or it is possible to observe the state when writing was in progress. — Some Name, Jun 15 '20 at 21:07
`inotify` doesn't even provide actual guarantees that you'll receive all events. See [**inotify missing events**](https://stackoverflow.com/questions/15806488/inotify-missing-events), and [**Why is inotify losing events?**](https://stackoverflow.com/questions/8454827/why-is-inotify-losing-events) among many others, Per [the `inotify` man page](https://man7.org/linux/man-pages/man7/inotify.7.html): "Robust applications should handle the possibility of lost events gracefully." File systems are not message queues - don't try to force them to be. — Andrew Henle, Jun 22 '20 at 14:42

secret squirrel · Answer 1 · 2020-06-22T14:05:24.063

The inotify subsystem does not have any gaurantees about ordering from a users perspective. See the file /fs/notify/notification.c in the kernel code. The opening comment says this:

Basic idea behind the notification queue: An fsnotify group (like inotify) sends the userspace notification about events asynchronously some time after the event happened. When inotify gets an event it will need to add that event to the group notify queue.

At the "other end", the inotify handler sits in a loop waiting to read events off the queue, see the file fs/notify/inotify_user.c. As you can see, there is only a gaurantee that an event will be reported some time after it happens. However, from the kernels point of view, ordering is preserved.

There is another point that should answer up your question though. If you look at the list of events that can be watched, in linux/inotify.h:

/* the following are legal, implemented events that user-space can watch for */
#define IN_ACCESS       0x00000001  /* File was accessed */
#define IN_MODIFY       0x00000002  /* File was modified */
#define IN_ATTRIB       0x00000004  /* Metadata changed */
#define IN_CLOSE_WRITE      0x00000008  /* Writtable file was closed */
#define IN_CLOSE_NOWRITE    0x00000010  /* Unwrittable file closed */
#define IN_OPEN         0x00000020  /* File was opened */
#define IN_MOVED_FROM       0x00000040  /* File was moved from X */
#define IN_MOVED_TO     0x00000080  /* File was moved to Y */
#define IN_CREATE       0x00000100  /* Subfile was created */
#define IN_DELETE       0x00000200  /* Subfile was deleted */
#define IN_DELETE_SELF      0x00000400  /* Self was deleted */
#define IN_MOVE_SELF        0x00000800  /* Self was moved */

/* the following are legal events.  they are sent as needed to any watch */
#define IN_UNMOUNT      0x00002000  /* Backing fs was unmounted */
#define IN_Q_OVERFLOW       0x00004000  /* Event queued overflowed */
#define IN_IGNORED      0x00008000  /* File was ignored */

You can see that IN_MODIFY will be set after a file was opened and writing was started without anything about writing being finished; but IN_CLOSE_WRITE happens after the file descriptor was closed. So, if you're worried about race conditions between different user programs writing to the same files you can watch for IN_CLOSE_WRITE.

Inotify write visibility guarantees

1 Answers1