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

[Tassilo Horn <tsdh@gnu.org>]

Tassilo Horn <tsdh@gnu.org> writes:

>> Even the straigt forward cases are not covered well in
>> file-notify-tests.el.  There is a test whether events arrive, but the
>> nature of the events is not asserted.
>>
>> You could try with what you expect, at least for inotify, and Eli and
>> I could check then for the gfilenotify and w32notify cases. If we
>> have the same results, fine; if we have different results it would be
>> a good chance for us to harmonize.
>
> That's right.  I'll try adding some tests whenever I find some time.

Ok, I gave it a whirl and now the `file-notify--test-event-handler' also
records all events in a new variable `file-notify--test-events' for
later analysis.  `file-notify-test02-events' now uses that feature to
check if the received events are the expected ones in the expected
order.

That already revealed two problems:

  1. Now `file-notify-test02-events-remote' fails because after every
     expected `changed' event an additional `attribute-changed' event is
     received.  This is wrong because when adding the watch, only
     '(change) is given as FLAGS argument, not '(change
     attribute-change).

  2. When I change the watch FLAGS to '(change attribute-change), there
     are still no attribute-changed events received in the local case.

And a question: Will the events read by `file-notify--wait-for-events'
still be processed by the handler function?

And what's the intention of (file-notify--wait-for-events 5
file-notify--test-results)?  The timeout of 5 is reasonable, but the
UNTIL argument here just defines that it waits until the very first of
possibly up to nine yet missing events is awaited here, or do I get
something wrong?

Bye,
Tassilo