Re: New file notification event `stopped'

[Michael Albinus <michael.albinus@gmx.de>]

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.

> Anyway, my response boils down to this: I don't think we should make
> notification back-ends invent events that are not reported by the
> respective OS facilities.  Doing that is the job of filenotify.el.

D'accord. I have no specific plan yet how to implement this in the
backends, maybe they could be kept untouched. I've tried to show that
inotify.c sends already the needed event (`ignored'), and gfilenotify.c
seems also to send useful events about (`deleted', `renamed' and
`unmounted'). Maybe there is indeed nothing to do. If this is also the
case for w32notify.c - even better.

> 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?

In the latter case, we would need a trigger indeed. Maybe sending an
additional `removed' event for the directory could be an option?

> 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.

Best regards, Michael.