mirror of https://github.com/mkerrisk/man-pages
fanotify.7: Rework and enhance text introducing read() and events
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
6c693f6de5
commit
c9120323bf
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue