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

Previous Next

Package: emacs;

Reported by: Tassilo Horn <tsdh <at> gnu.org>

Date: Tue, 8 Sep 2015 06:37:01 UTC

Severity: normal

Found in version 25.0.50

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

Bug is archived. No further changes may be made.

Full log


Message #29 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, 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 20:09:52 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.
>
> But the issue comes up before you remove the watch.  You have a watch
> that is in fact inoperable, but the application might not know about
> that, or get hit by a signal out of nowhere.
>
> So I think having a validation function is a good idea.

Yes. I've started to write a prototype for inotify.c, will show when it
works (slow progress, you know :-( )

>> At least inotify removes a watch internally, when it detects that the
>> file/directoy to be watched does not exist any longer.
>
> That's a bug, IMO: it shouldn't.

I tend to agree. Will check further with inotify.c, but likely we should
discard this "feature".

>> 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.
>
> I don't think you can easily raise a signal.  I think we should
> provide a validate function for the applications to use.

At least for inotify, it is built-in. It sends the `ignored' signal when
the directory or file being watch disappears, due to a delete, rename, or
unmount, whatever:

--8<---------------cut here---------------start------------->8---
(progn
  (trace-function 'file-notify-handle-event)
  (write-region "any text" nil "/tmp/xxx")
  (inotify-add-watch "/tmp/xxx" 'all-events 'ignore)
  (delete-file "/tmp/xxx"))

======================================================================
1 -> (file-notify-handle-event (file-notify (1 (attrib) nil 0) ignore))
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (delete-self) nil 0) ignore))
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (ignored) nil 0) ignore))
1 <- file-notify-handle-event: nil
--8<---------------cut here---------------end--------------->8---

For gfilenotify it isn't such simple, unfortunately.

Best regards, Michael.




This bug report was last modified 9 years and 246 days ago.

Previous Next


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