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

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

[Noam Postavsky]

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).  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.  I'm not sure if it should
be considered a bug, or just an inherent limitation of Windows' file
notification API.

The original context for this was a magit bug, since fixed by changing
to sleep-for (and hopefully will soon be better fixed by using
call-process-region instead of start-process + busy wait):
https://github.com/magit/magit/issues/2454


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Begin file-notify-and-sit-for-test.el
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'filenotify)

;; simulate the problematic effect of `global-auto-revert-mode'
(file-notify-add-watch load-file-name '(change) #'ignore)

(call-process "git" nil nil nil "update-index" "--refresh")

(let ((proc (start-process "git version" nil "git" "--version")))
  (message "waiting for %s" (process-id proc))
  (while (eq (process-status proc) 'run)
    (sit-for 0.1)
    (message "waiting for %s" (process-id proc))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; End file-notify-and-sit-for-test.el
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

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.

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

[Noam Postavsky]

On Sun, Jan 24, 2016 at 10:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> When you ask to watch a file, file-notify-add-watch actually watches
> the entire directory of that file

Oh.  In this case I thought it was only files beneath .git/ that were
being changed (while we we are watching a file in the working copy),
but (trace-function 'file-notify-callback) tells me that Emacs is
receiving events about the .git/ directory.

>> This does not occur on GNU/Linux systems.
>
> Did those systems use inotify or the gfilenotify back-end?

I think gfilenotify, but I only have access to a Windows box for the
next couple of weeks, so I'm not 100% sure.

> 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.

Ok, sounds like there is nothing to fix on the Emacs side, so I'm closing this.

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

[Eli Zaretskii]

> Date: Sun, 24 Jan 2016 11:46:14 -0500
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: 22454-done@debbugs.gnu.org
> 
> On Sun, Jan 24, 2016 at 10:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > When you ask to watch a file, file-notify-add-watch actually watches
> > the entire directory of that file
> 
> Oh.  In this case I thought it was only files beneath .git/ that were
> being changed (while we we are watching a file in the working copy),
> but (trace-function 'file-notify-callback) tells me that Emacs is
> receiving events about the .git/ directory.

Adding or deleting files inside .git/ modifies that directory on
MS-Windows, so I think that's what you see.

> Ok, sounds like there is nothing to fix on the Emacs side, so I'm closing this.

Thanks.