Jan, I am struggling with an attempt to extend the fanotify API and I wanted to ask your opinion before I go too far in the wrong direction. I am working with an application that used to use inotify rename cookies to match MOVED_FROM/MOVED_TO events. The application was converted to use fanotify name events, but the rename cookie functionality was missing, so I am carrying a small patch for FAN_REPORT_COOKIE. I do not want to propose this patch for upstream, because I do not like this API. What I thought was that instead of a "cookie" I would like to use the child fid as a way to pair up move events. This requires that the move events will never be merged and therefore not re-ordered (as is the case with inotify move events). My thinking was to generalize this concept and introduce FAN_REPORT_CHILD_FID flag. With that flag, dirent events will report additional FID records, like events on a non-dir child (but also for dirent events on subdirs). Either FAN_REPORT_CHILD_FID would also prevent dirent events from being merged or we could use another flag for that purpose, but I wasn't able to come up with an idea for a name for this flag :-/ I sketched this patch [1] to implement the flag and to document the desired semantics. It's only build tested and I did not even implement the merge rules listed in the commit message. [1] https://github.com/amir73il/linux/commits/fanotify_child_fid There are other benefits from FAN_REPORT_CHILD_FID which are not related to matching move event pairs, such as the case described in this discussion [2], where I believe you suggested something along the lines of FAN_REPORT_CHILD_FID. [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhEsbfA5+sW4XPnUKgCkXtwoDA-BR3iRO34Nx5c4y7Nug@xxxxxxxxxxxxxx/ Thoughts? Amir.
