bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted

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

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I don't have a strong opinion about what the right behavior would be but
>>> at least it seems inconsistent that you get the error only with deleted
>>> directories.
>>
>> There is no "right" behavior.  What you see is what the back-end
>> reports to us.  If we want Emacs to be smarter, it's the job of the
>> application, not of filenotify.el.
>
> Well, filenotify.el shall abstract from the different back-ends. Being
> quiet when the native rm-watch fails seems to be appropriate.

I've checked, all three Emacs libraries inotify, gfilenotify and
w32notify return an error when *-rm-watch detects a problem.
`file-notify-rm-watch' could propagate this error. The manual
shall be extended then.

At least inotify removes a watch internally, when it detects that the
file/directoy to be watched does not exist any longer. gfilenotify and
w32notify do not seem to to care.

Shall we unify this behaviour? I'm not in favor of the inotify
behaviour, the libraries shall raise a final signal instead that the
watch is stopped. filenotify shall propagate this then, for example as
`stopped' event or something like this.

Last point, I've observed that inotify and gfilenotify raise a
`file-notify-error' when needed. w32notify raises a `file-error'.
Shouldn't it raise also `file-notify-error'?.

Best regards, Michael.