fanotify_init.2, fanotify.7: Minor edits to Amir Goldstein's patches

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2020-08-28 14:26:12 +02:00
parent 1a1e4638a5
commit 0bda7dedcf
2 changed files with 10 additions and 10 deletions

View File

@ -238,7 +238,7 @@ This flag may be combined with the flag
.BR FAN_REPORT_FID .
An additional record of type
.BR FAN_EVENT_INFO_TYPE_DFID_NAME ,
which encapsulates the information about the directory entry is included
which encapsulates the information about the directory entry, is included
alongside the generic event metadata structure and substitutes the additional
information record of type
.BR FAN_EVENT_INFO_TYPE_DFID .
@ -265,7 +265,7 @@ the reported name can be used to call
The same rule that applies to record type
.BR FAN_EVENT_INFO_TYPE_DFID
also applies to record type
.BR FAN_EVENT_INFO_TYPE_DFID_NAME \ -
.BR FAN_EVENT_INFO_TYPE_DFID_NAME :
if a non-directory object has no parent, either the event will not be reported
or it will be reported without the directory entry information.
Note that there is no guarantee that the filesystem object will be found at the

View File

@ -111,7 +111,7 @@ events and
.I permission
events.
Notification events are merely informative and require no action to be taken
by the receiving application with one exception - if a valid file descriptor
by the receiving application with one exception: if a valid file descriptor
is provided within a generic event, the file descriptor must be closed.
Permission events are requests to the receiving application to decide
whether permission for a file access shall be granted.
@ -174,9 +174,9 @@ structure within the read buffer:
.in +4n
.EX
struct fanotify_event_info_header {
__u8 info_type;
__u8 pad;
__u16 len;
__u8 info_type;
__u8 pad;
__u16 len;
};
struct fanotify_event_info_fid {
@ -415,8 +415,8 @@ When an fanotify file descriptor is created using the combination of
.BR FAN_REPORT_FID
and
.BR FAN_REPORT_DIR_FID ,
there may be two information records attached to the event.
One with
there may be two information records attached to the event:
one with
.I info_type
field value of
.BR FAN_EVENT_INFO_TYPE_DFID ,
@ -700,9 +700,9 @@ An additional mark must then be set on the newly created subdirectory.
This approach is racy, because it can lose events that occurred inside the
newly created subdirectory, before a mark is added on that subdirectory.
Monitoring mounts offers the capability to monitor a whole directory tree
in a race free manner.
in a race-free manner.
Monitoring filesystems offers the capability to monitor changes made from
any mount of a filesystem instance in a race free manner.
any mount of a filesystem instance in a race-free manner.
.PP
The event queue can overflow.
In this case, events are lost.