> > 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.
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/fan_rename
[2] https://github.com/amir73il/ltp/commits/fan_rename
