bug#81531: 30.2; filenotify: moving file out of watched directory delays the "deleted" event until file is later moved back in

> From: Michael Albinus <[email protected]>
> Cc: [email protected],  [email protected]
> Date: Sat, 08 Aug 2026 12:28:07 +0200
> 
> Eli Zaretskii <[email protected]> writes:
> 
> Hi Eli,
>  
> >> >     3 -> `mv bar ..`
> >> 
> >> --8<---------------cut here---------------start------------->8---
> >> file-notify-handle-event (file-notify ((1 . 0) (moved-from) "bar" 370367) file-notify--callback-inotify)
> >> --8<---------------cut here---------------end--------------->8---
> >> 
> >> This is the problematic action. We get from inotify only a 'moved-from
> >> "bar"' event. The corresponding 'moved-to' event is not returned,
> >> because the file path is ouside of the watched directory.
> >> 
> >> filenotify.el is instructed, to wait for the next backend event after
> >> 'moved-from'. This is needed to decide what to do. Since no second
> >> backend event arrives, nothing is sent to the handler. This is what you
> >> have observed.
> >
> > Maybe we should report both the low-level original events "moved-from"
> > and "moved-to", and the higher-level "renamed" events?  Then at least
> > the moved-from event will not be lost.  WDYT?
> 
> This would break the contract of file-notify.el, to show only the
> specified events. Low-level events are hidden for a reason: the user's
> handler function doesn't know them. All consuments of filenotify.el
> would need to extend their handlers.
> 
> And the situation is not as bad as it looks. The corresponding "delete"
> event, "renamed-from" is converted to if there is no matching
> "renamed-to", is delivered as soon as the next other event arrives. A
> short delay only, as the OP has also reported.
> 
> There might be the situation, that a file is moved outside the watched
> directory, and there is a pending "removed-from" which won't be handled
> because there is no other activity in the directory. This could be
> mitigated by calling read-event with a short timeout (even 0.01 should
> work), because in practive "removed-from" and "removed-to" events arrive
> almost simultaneously. If there is no "removed-to" event after this
> call, we could assume that "removed-from" must be reported as "deleted".
> 
> WDYT?

AFAIU, in this case what we do was not good enough, but maybe I
misunderstood.