> Let me list a few approaches to this problem that were floated in the past. > You may choose bits and parts that you find useful to your use case. Thanks for sharing these approaches for smoothly recovering pending events. > 3. Change the default response to pending events on group fd close > Support writing a response with > .fd = FAN_NOFD > .response = FAN_DENY | FAN_DEFAULT > to set a group parameter fanotify_data.default_response. > Instead of setting pending events response to FAN_ALLOW, > could set it to FAN_DENY, or to descriptive error like > FAN_DENY(ECONNRESET). I think that the approach of customizing group close behavior would likely address the problem of pending events in case of daemon restart / crash encountered by our use case. It gives us the same guarantee of clearing out pending event queue that we wanted while preventing any access of unpopulated content. The one ask related to this approach would be around the handover from old to new group fd. Would it be possible to provide an easy way to initialize one group from another (ie an fanotify_mark option). In our case we have an interested mount as well as a set of ignore marks for populated files to avoid regenerating events for. The moderated mount functionality discussed in this thread would also be helpful for better handling when the daemon is down.
