[Resending after unarchiving the bug.]


On 11/5/2015 2:58 PM, Michael Albinus wrote:
> I've played with this the whole afternoon. Looks like there is no error
> in gfilenotify for Cygwin. But it is a hard job to trigger the file
> notification events to appear such a way they could be checked for
> correctness in the test cases.
>
> Increasing timeouts was necessary. But even this does not make the
> events to appear reliably. One would need to write additional code to
> get every single event one after the other. Waiting for a series of
> events, as the test cases do expect, does not seem to work.

Hi Michael,

I've made some progress on understanding why some file notifications 
aren't triggered in the tests on Cygwin.  One issue is that 
file-notify--test-read-event-timeout has to be increased drastically in 
order for `created' and `changed' events to be received.  These can take 
5 seconds or more.

A second issue is that a small delay is needed between the creation of a 
file watch and the beginning of file activity.  This is not normally a 
problem in interactive sessions.  But it can be observed in an 
interactive session by evaluating the following:

(require 'filenotify)
filenotify

(defun my-notify-callback (event)
    (message "Event %S" event))

(progn
    (file-notify-add-watch
     "/tmp/foo" '(change) 'my-notify-callback)
    (write-region "" nil "/tmp/foo"))

(delete-file "/tmp/foo")

;; The above yields `deleted' and `stopped' events, but no `created' 
event.  Now we introduce a delay after adding the watch.

(progn
    (file-notify-add-watch
     "/tmp/foo" '(change) 'my-notify-callback)
    (sleep-for 1)
    (write-region "" nil "/tmp/foo"))

(delete-file "/tmp/foo")

;; This time we get the expected `created' event.

The attached patch takes care of both timing issues.  With this patch, 
all the inexpensive file-notify tests pass on all my Cygwin systems.

Best regards,

Ken