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

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> w32notify reports 2 changed events in a row:
>
>   Test file-notify-test02-events condition:
>       (ert-test-failed
>        ((should
> 	 (equal '...
> 	  (mapcar ... events)))
> 	:form
> 	(equal
> 	 (created changed deleted)
> 	 (created changed changed deleted))
> 	:value nil :explanation
> 	(proper-lists-of-different-length 3 4
> 					  (created changed deleted)
> 					  (created changed changed deleted)
> 					  first-mismatch-at 2)))
>
> This is the "copy" part of the test.  Interestingly, sometimes there
> are 2 separate "changed" events and sometimes only 1.  Does
> filenotify.el try to conflate several consecutive events of the same
> kind into one?  In any case, I guess we will have to allow either one
> or 2 "changed" events there.

No, filenotify.el handles them as they are. The only change in the event
flow is, when two consecutive deleted+created events are combined to a
renamed event.

However, as said I have extended the test case a little bit. There are
now set-file-times and set-file-modes calls, which shall result in
attribute-changed events. And those events shall be suppressed, because
we start file notifications with (file-notify-add-watch ... '(change) ...)

How does w32notify report attribute changes? Could you, please, call
(trace-output 'file-notify-handle-event) and rerun file-notify-test02-events?

Best regards, Michael.