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

Previous Next

Full log

Message #23 received at 21432 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21432 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#21432: 25.0.50;
 file-notify-rm-watch (inotify) errors if watched dir is deleted
Date: Sat, 12 Sep 2015 12:18:01 +0200

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

> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.