Unfortunately, fanotify does not inform listeners for all paths
under which a touched filesystem object is visible, but only the
listener using the same path as the process touching the
filesystem object.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fallocate(2) should create FAN_MODIFY events but does not.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I bumped the Linux version number in the BUGS section to 3.17.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk pointed me to alignment issues which may
arise when reading misaligned integers.
On some systems integer values can only be read if they are
correctly aligned. Other system have a lower performance when
reading from or writing to misaligned memory positions.
Therefore, the buffer used to call read(2) for a fanotify
file descriptor should have the same alignment as
struct fanotify_event_metadata.
Due to the casting to char* inside the macros
FAN_EVENT_OK and FAN_EVENT_NEXT we can use any
data structure for the buffer.
With the patch an array of struct fanotify_event_metadata is
used as buffer which seems a natural choice to ensure proper
alignment.
It should be remembered that the offset between events is given
by field event_len and iterating over the array may not be
allowable in future. Instead the macros should be used.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FAN_EVENT_NEXT() does not update 'meta'; rather, it returns a
pointer to the next metadata structure. In addition, generally
rework the description to be a bit clearer and more detailed.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Note the use of fanotify_mark() 'event_f_flags' to control
the file status flags for the file descriptors returned via
'fanotify_event_metadata.fd'.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Using large buffer sizes for read(2) is orthogonal to the
discussion of variable-length event structures.
* Move the discussion of the read() return value to follow
discussion of what the read() actually returns in its buffer.
* Related rewordings.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Update as per http://www.spinics.net/lists/linux-man/msg05624.html
where Jan Kara proposed to clarify the deletion of events from the
fanotify queue and the occurrence of ENOENT when writing to the
fanotify file descriptor.
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A bug mentioned in fanotify_mark(2) need not be repeated in
fanotify(7) again.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
poll() and ppoll() are not among the primary calls in the API
(and anyway, select(), pselect(), and epoll were not mentioned).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Heinrich Schuchardt