Hello :-) I want to use fanotify to construct a best-effort log of changes to the filesystem over time. It would be super useful if events like FAN_MOVE_SELF and FAN_DELETE_SELF could report the path that the file _was_ at just prior to the event. Reporting an FID value is of limited use, because even if it still exists, looking up the name (e.g. by open_by_handle_at, the way fatrace does) will only reveal the new name after a FAN_MOVE_SELF -- and after a FAN_DELETE_SELF, the file no longer has any path! I understand that in terms of a strictly accurate reconstruction of changes over time, fanotify events are of limited use, because they aren't guaranteed to be ordered and from what I have read it seems it is possible for some changes to "slip through" from time to time. But, this is not a problem for my use case. I have no idea what things are available where in the kernel code that generates these events, but in the course of writing the code that reads the event data that gets sent to an fanotify fd, I was thinking that the simplest way to achieve this would be for FAN_MOVE_SELF and FAN_DELETE_SELF events to have associated info structures with paths in them. FAN_DELETE_SELF could provide an info structure with the path that just got unlinked, and FAN_MOVE_SELF could provide two info structures, one for the old path and one for the new. Of course, it is possible that this information isn't currently available at the spot where the events are being generated! But, this would be immensely useful to my use case. Any possibility? Thanks, Jonathan Gilbert
