|Subject:||bug#22534: File notify broken on Windows|
|Date:||Fri, 5 Feb 2016 06:59:00 +0100|
> From: Fabrice Popineau <address@hidden>
> Date: Thu, 4 Feb 2016 10:49:42 +0100
> Cc: Eli Zaretskii <address@hidden>, address@hidden
> - 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
> 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.
> - 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?
> 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?
> 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
|[Prev in Thread]||Current Thread||[Next in Thread]|