On Thu, Nov 18, 2021 at 6:29 PM Jan Kara [off-list ref] wrote:
On Thu 18-11-21 14:47:18, Amir Goldstein wrote:
quoted
quoted
quoted
So let's say this - we can add support for OLD_DFID, NEW_DFID types
later if we think they may serve a purpose, but at this time, I see no
reason to complicate the UAPI anymore than it already is and I would
rather implement only:
/* Info types for FAN_RENAME */
#define FAN_EVENT_INFO_TYPE_OLD_DFID_NAME 10
/* Reserved for FAN_EVENT_INFO_TYPE_OLD_DFID 11 */
#define FAN_EVENT_INFO_TYPE_NEW_DFID_NAME 12
/* Reserved for FAN_EVENT_INFO_TYPE_NEW_DFID 13 */
Do you agree?
I agree the utility of FAN_RENAME without FAN_REPORT_NAME is very limited
so I'm OK with not implementing that at least for now.
OK. The patches are staged at [1], but I ran into one more UAPI question
that I wanted to run by you before posting the patches.
The question may be best described by the last commit on the tests branch [2]:
syscalls/fanotify16: Test FAN_RENAME with ignored mask
When a file is moved between two directories and only one of them is
watching for FAN_RENAME events, the FAN_RENAME event will include only
the information about the entry in the watched directory.
When one of the directories is watching FAN_RENAME, but the other is
ignoring FAN_RENAME events, the FAN_RENAME event will not be reported
at all.
This is not the same behavior as MOVED_FROM/TO events. User cannot
request to ignore MOVED_FROM events according to destination directory
nor MOVED_TO events according to source directory.
I chose this behavior because I found it to be useful and consistent with
other behaviors involving ignored masks. Maybe "chose" is a strong word
here - I did not do anything to implement this specific behavior - it is just
how the code in fanotify_group_event_mask() works for merging masks
and ignored masks of different marks.
Let me know if you approve of those ignored FAN_RENAME semantics
and I will post the patches for review.
Yeah, I guess ignore masks with FAN_RENAME are going to be a bit
non-intuitive either way and what you suggest makes sense. I suppose when
SB has FAN_RENAME mark and either source or target have FAN_RENAME in the
ignore mask, nothing will get reported as well, do it? If we are consistent
like this, I guess fine by me.
Yes, that is correct, because the join of combined masks and combined
ignored_masks is done at the very end, if an event is in ignored mask of
any related mark, it will cause the drop of the event.
I will post patches soon.
Thanks,
Amir.