GNU bug report logs - #22534
File notify broken on Windows

Previous Next

Full log

Message #44 received at 22534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 22534 <at> debbugs.gnu.org, fabrice.popineau <at> gmail.com
Subject: Re: bug#22534: File notify broken on Windows
Date: Fri, 05 Feb 2016 21:43:26 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  22534 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.