bug#22454: 24.5; win32 file-notify, input events caused by updates to other (non-watched) files

[Eli Zaretskii]

> Date: Sun, 24 Jan 2016 03:10:38 -0500
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> 
> Save the lisp code below to a file in a git checkout, and run it with
> 'emacs -Q -l file-notify-and-sit-for-test.el'.  It causes Emacs to get
> stuck in an infinite loop (you can exit with C-g).  It seems that the
> 'git update-index --refresh' writes to somes files in .git/ which
> triggers a file notify event (even though Emacs is not watching those
> files).

When you ask to watch a file, file-notify-add-watch actually watches
the entire directory of that file (because some file operations need
to see more than just one file).  Filtering of events that don't
pertain to the file you asked to watch happens on the Lisp level, when
the notification event is processed by the Lisp callback set up by
filenotify.el.

> This causes 'sit-for' to return immediately, and the process-status
> of 'git --version' never gets set to 'exit' (even though the actual
> process does exit quickly).
> 
> This does not occur on GNU/Linux systems.

Did those systems use inotify or the gfilenotify back-end?

> I'm not sure if it should be considered a bug, or just an inherent
> limitation of Windows' file notification API.

I don't think it's either a bug or a limitation.  File notifications
generate input events, so the current implementation of sit-for has a
good reason to stop waiting.  The way the input events are generated
differ between different back-ends, so perhaps the difference in
behavior you see is due to that, but in general I think the fact that
you didn't see that on GNU/Linux is more luck than anything else.

Thanks.