bug#21435: 25.0.50; file-notify has problems after renames

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Another thing is that renames always seem to be reported twice
>> (although the example in the manual lists only one event but that
>> example has probably gathered with the gfilenotify backend).
>
> This doesn't happen with w32notify.  filenotify.el includes some code
> to produce a single notification out of the 2 reported by back-ends in
> this case; perhaps something doesn't work there with inotify.  Can you
> step through the code and see why?

I stepped through inotify_callback in inotify.c which can read 64 byte
from inotifyfd where the size of one inotify event is 32 and that
produces 2 emacs events (although I cannot see which events are
created).  The Locals GUD frame always shows just nil for the `event'
local variable even after the assignments to it and I stepped into the
then-branch of an `if (!NILP(event.arg))' which makes it pretty clear
that it cannot be nil.  Why is that?

Then I turned to `file-notify-callback'.  That receives one `move-from'
event and one `move-to' event which I figured out by adding a message.
The problem is that as soon as I edebug the function, I can only see the
first call for the `mode-from' event.  After stepping through it, I
won't be put into the debugger for the second event as if it has been
discarded in the meantime.  My handle function is also not run when
edebugging.  Is that expected that when edebugging event handlers one
might miss events?

Anyway, eventually I found and fixed the culprit which simply was that
the watch descriptors of the pending and the current event were compared
with `eq' which is not valid because inotify descriptors are conses.
I've changed the comparison to `equal' which fixes the double-reporting
issue.

Bye,
Tassilo