Missing DFidName handling, seen with REPORT_NAME

[tv42]

If you specify fanotify::init::Flags::REPORT_NAME, the read results (can?) have a second header that contains the path segment that changed. This triggers a TooShort error (with a misleading message, since there's extra data), due to a if found != expected test.

fanotify/src/event/iterator.rs

Lines 156 to 162 in 07703f3

	if found != expected {
	return Err(TooShort {
	what: FidEvent,
	found,
	expected,
	});
	}

If I change that to if found < expected, the code works again, but ignores the extra data. Printing it out reveals the first byte is 2, hence fanotify_event_info_fid.hdr.info_type == 2, FAN_EVENT_INFO_TYPE_DFID_NAME. And it seems this library can request names, but cannot parse them.

It seems EventIterator was written to assume there's only one fanotify_event_info_fid, but as far as I understand that's not guaranteed. I would suggest the code be changed to treat it as a sequence, and silently ignore unrecognized info_type values. That change didn't up being quite trivial enough for me to program it quickly..

[tv42]

Confirmation:

fanotify/src/event/file/fid.rs

Line 18 in 07703f3

/// TODO there can be multiple of these per event, so need to handle that

[tv42]

One discovery that was a bit too subtly documented:

If the value of info_type field is
FAN_EVENT_INFO_TYPE_DFID_NAME, the file_handle identifies
the same directory object that would be reported with
FAN_EVENT_INFO_TYPE_DFID and the file handle is followed
by a null terminated string that identifies the name of a
directory entry in that directory, or '.' to identify the
directory object itself.

https://man7.org/linux/man-pages/man7/fanotify.7.html

That is, FAN_EVENT_INFO_TYPE_DFID_NAME should be read as "DirFID and name". If you request REPORT_NAME, you never see FAN_EVENT_INFO_TYPE_DFID, just FAN_EVENT_INFO_TYPE_DFID_NAME.