Re: New file notification event `stopped'

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

Michael Albinus <michael.albinus@gmx.de> writes:

> Hi,

Hi,

> during the work on bug#21432 and bug#21435, we have introduced a new
> function `file-notify-valid-p', which tells whether a given monitor is
> still active. We have also discussed shortly, whether a monitor should
> signal, when it stops its activities. A monitor could cease to work for
> different reasons, maybe because it is cancelled (not only by
> `file-notify-rm-watch'), maybe because the file/directory to be watched
> is deleted, maybe because some internal limits are reached.
>
> Therefore, I propose that a new file notification event `stopped' shall
> be added to the file notification events to be raised by a file
> notification monitor. This would allow applications to react directly on
> this situation. For example, `auto-revert-mode' could switch to polling
> then.
>
> The implementation for inotify.c is simple, because it receives already
> the native IN_IGNORED event in this case, which could be mapped easily
> to the `stopped' event.
>
> The implementation for gfilenotify.c would create such a `stopped'
> event, if one of the native events G_FILE_MONITOR_EVENT_DELETED,
> G_FILE_MONITOR_EVENT_RENAMED or G_FILE_MONITOR_EVENT_UNMOUNTED was
> received, and the file argument is equal to the watched file or
> directory.
>
> I hope a simlar mechanism could be implemented for w32notify.c.
>
> Comments?

Nobody did reply. So I will implement it next days for inotify.c,
gfilenotify.c and Tramp. Maybe Eli could add an implementation for
w32notify.c.

Best regards, Michael.