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

Previous Next

Package: emacs;

Reported by: Fabrice Popineau <fabrice.popineau <at> gmail.com>

Date: Tue, 2 Feb 2016 06:25:02 UTC

Severity: normal

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22534 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: bug#22534: File notify broken on Windows
Date: Fri, 5 Feb 2016 06:59:00 +0100
[Message part 1 (text/plain, inline)]
2016-02-04 19:47 GMT+01:00 Eli Zaretskii <eliz <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> > Date: Thu, 4 Feb 2016 10:49:42 +0100
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 22534 <at> debbugs.gnu.org
> >
> > - notifications returned are not the same whether you run the tests in
> batch mode or interactive mode.
> > In interactive mode, there is a deleted notification which is sent when
> your remove the directory being
> > watched.
> > This event is not seen when running in batch mode (make check). I wonder
> what could make a difference.
>
> Support for file notifications in batch mode is fragile: w32notify
> normally works by sending a message to the main thread whenever it has
> a notification to report.  But in batch mode, the main thread doesn't
> read Windows messages, so whether an event gets reported depends on
> whether 'pselect' is called, which depends on what API is called to
> wait for notifications and read them.
>
>
Ok. Maybe that's the reason, but in this case, the expected events have to
be adjusted because 'make check'
runs in batch mode.


> > - in the test file-notify-test06-many-events to check that events
> > are not dropped : I have to lower the 1000 number.  The test fails
> > as soon as I go higher than around 260. Is there some limit here ?
>
> Is this in interactive or a batch-mode run?
>
> In interactive mode. The limit is somewhere between 260 and 280.


> > Once the limit is reached, only  the first notification is returned.
>
> What do you mean by "the first notification"?  AFAIU, the 1000 events
> are generated as 500 pairs of renames, so what is "the first" here,
> after 260 were already generated?
>
>
The notification for the first pair in the list, the one numbered 999 is
the only one
appearing in file-notify--test-events.


> > Overall, I don't think anymore that the patch by Michael has broken w32
> file notifications
> > but rather that the new tests have highlighted some potential problems
> with it.
>
> I've just found a serious problem, see bug#22557.  I'm not sure it is
> related to what you see here, but IMO until that bug is resolved,
> there's no sense in trying to analyze what happens with notifications
> on MS-Windows.
>

Ok, I have seen that. Maybe I'll try to comment out the part of the patch
you have pointed out in this bug report
and see how it changes the behavior.

Fabrice
[Message part 2 (text/html, inline)]

This bug report was last modified 9 years and 61 days ago.

Previous Next


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