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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
