On Thu, Nov 18, 2021 at 6:29 PM Jan Kara <jack@xxxxxxx> wrote: > > On Thu 18-11-21 14:47:18, Amir Goldstein wrote: > > > > 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.
