Re: New file notification event `stopped'

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 10 Oct 2015 13:56:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Nobody did reply.
> >
> > I did.  Or I thought I did, but now I cannot find my response in the
> > archives.  Maybe it's my imagination, or maybe it has something to do
> > with the recent snafu in GNU mailman archives.
> 
> At least I haven't received an email from you on this topic. Usually,
> you Cc the sender of a message.

Yes.  I guess I was dreaming.  It happens.

> > In addition, I don't know how to implement this in w32notify.c, at
> > least not easily.  As I said, when the watched directory is deleted,
> > the thread that watches exits with an error status, that's all.
> 
> But isn't there at least the `removed' event? Or is it just for files of
> the watched directory, and not the directory itself?

The latter, AFAIR.

> > What problem should this 'stopped' event solve?  Do we really have a
> > real-life problem here, and if so, couldn't we solve it in some other
> > manner?
> 
> Imagine you have a file under supervision in auto-revert-mode. If the
> watch is broken or removed (by a *-rm-watch call), autorevert could
> still work due to the polling mechanism in autorevert.el.

Shouldn't it be possible to test the validity from time to time?