bug#22534: File notify broken on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  22534@debbugs.gnu.org
> Date: Fri, 05 Feb 2016 18:18:59 +0100
> 
> > I have tried with different values of file-notify--test-timeout but it
> > doesn't seem to make any difference. I also boosted the size of the
> > file_notifications[] array (* 16) without any difference. I have
> > tested with sit-for between each rename operation and it does not work
> > either above 260 files
> 
> Is it worth to continue to look for the problem in w32notify? I would simply
> set the loop limit there to 250, that's it.

It would be a waste of your time to look into that.  Go ahead and
lower the number; I will look into the problem when I have time and
see what come up with.  We can then pick up where we left off.

> file-notify-test06-many-events is a stress test. Originally, Wolfgang
> Jenkner proposed it with 10.000 iterations - that was *really* much too
> long.
> 
> [Eli]
> 
> >     (To tell the truth, I'm not sure what is the purpose of that test:
> >     AFAIK, none of the available notification back-ends ever promised
> >     not to lose events, so what are we testing here? Perhaps Michael
> >     can explain.)
> 
> As said, it was intended as stress test. But we are free to adapt it to
> the limitations of the underlying backend.

My point is that we could legitimately lose events for reasons that
have nothing to do with Emacs.