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

Hi Michael (sorry for the double email, I accidentally left out the CC in my
prior email),

> 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".

As I understand it with the current implementation of filenotify, is directly
reading the inotify events the only way to detect if a file is moved out of a
watched directory into an unwatched directory without waiting for another
filenotify event ?

On Wed, Aug 12, 2026 at 4:31 AM i_ix_iv <[email protected]> wrote:
>
> Hi Michael,
>
> > 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".
>
> As I understand it with the current implementation of filenotify, is directly
> reading the inotify events the only way to detect if a file is moved out of a
> watched directory into an unwatched directory without waiting for another
> filenotify event ?
>
>
> On Sat, Aug 8, 2026 at 11:58 AM Michael Albinus <[email protected]> wrote:
> >
> > Eli Zaretskii <[email protected]> writes:
> >
> > Hi Eli,
> >
> > >> 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.
> >
> > According to the data the OP has provided, we have fired all expected
> > events. The "delete" event came later as expected, that's all. My
> > proposal tries to mitigate this.
> >
> > Will try to implement a POC with an additional read-event after
> > "removed-from". This might be delayed a little bit, you know, summer
> > break (not mine, but our grand-son will be here).
> >
> > Best regards, Michael.