From c9120323bf6e53d234b05c025f80aea68e59d70f Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Fri, 25 Apr 2014 11:18:02 +0200 Subject: [PATCH] fanotify.7: Rework and enhance text introducing read() and events Signed-off-by: Michael Kerrisk --- man7/fanotify.7 | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/man7/fanotify.7 b/man7/fanotify.7 index cbaed33a5..d424c24c5 100644 --- a/man7/fanotify.7 +++ b/man7/fanotify.7 @@ -92,17 +92,27 @@ via their inode number and to mounts via their mount ID. If files or directories are renamed or moved, the respective entries survive. If files or directories are deleted or mounts are unmounted, the corresponding entries are deleted. -.PP -Two types of events exist: notification events and permission events. -Notification events are only informative and require no action to be taken by +.SS Events, the event queue, and reading events +As events occur on the filesystem objects monitired by a notification group, +the fanotify system generates events that are collected in a queue. +These events can then be read (using +.BR read (2) +or similar) +from the fanotify file descriptor +returned by +.BR fanotify_init (2). + +Two types of events are generated: +notification events and permission events. +Notification events are merely informative +and require no action to be taken by the receiving application except for closing the file descriptor passed in the event. Permission events are requests to the receiving application to decide whether permission for a file access shall be granted. For these events, the recipient must write a response which decides whether access is granted or not. -.SS Events, the event queue, and reading events -All events for an fanotify group are collected in a queue. + Consecutive events for the same filesystem object and originating from the same process may be merged into a single event, with the exception that two permission events are never merged into one queue entry.