GNU bug report logs -
#21435
25.0.50; file-notify has problems after renames
Previous Next
Reported by: Tassilo Horn <tsdh <at> gnu.org>
Date: Tue, 8 Sep 2015 08:48:01 UTC
Severity: normal
Found in version 25.0.50
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> 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.
This bug report was last modified 9 years and 307 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.