fanotify.7: Rework and enhance text introducing read() and events

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-04-25 11:18:02 +02:00
parent 6c693f6de5
commit c9120323bf
1 changed files with 15 additions and 5 deletions

View File

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