bug#21804: 25.0.50; file-notify-tests failure on Cygwin

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> Hi Michael,

Hi Ken,

> I just looked at the sources also, and the reason for the roughly
> 5-second delays I've been observing is clear.  In
> gio/gpollfilemonitor.c we have the following:
>
> #define POLL_TIME_SECS 5
> [...]
> schedule_poll_timeout (GPollFileMonitor* poll_monitor)
> {
>   poll_monitor->timeout = g_timeout_source_new_seconds (POLL_TIME_SECS);
> [...]
> }
>
> So I guess there's no way to avoid using a value of
> file-notify--test-read-event-timeout bigger than 5.

Yes, for a polling gfilenotify.

I've added the new function Fgfile_monitor_name to gfilenotify.c. It
tells us the name of the used monitor. In my case (GNU/Linux), it is
GInotifyFileMonitor. In your case it is GPollFileMonitor.

Based on this, we could detect better which timeout to use in
filenotify-tests.el. I worked on this, and the non-remote cases seem to
be OK now (although sometimes not all events do arrive). You could play
also with this, just call from Emacs root directory

# make -C test filenotify-tests

I recommend to change the value of n to 10 temporarily in both
file-notify-test06-many-events and
file-notify-test08-watched-file-in-watched-dir; otherwise the tests last
too long. If you want to run just one test case, call (for example)

# make -C test filenotify-tests SELECTOR='\"file-notify-test06-many-events$$\"'

SELECTOR is a regexp over test case names.

Installing the cygwin package "gvfs" brings you gvfs-monitor-dir.exe. If
available, the remote test cases are not skipped anymore.

> Best regards,
>
> Ken

Best regards, Michael.

PS: Could you pls provide on your site a recompiled Emacs? I would like
to use the changed gfilenotify.c. Thanks!