From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Date: Tue, 08 Sep 2015 10:11:59 +0200 Message-ID: <8737yp5nzk.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <87wpw1uzd0.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441700004 9756 80.91.229.3 (8 Sep 2015 08:13:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 08:13:24 +0000 (UTC) Cc: 21432@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 08 10:13:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZE1f-000767-9I for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 10:13:11 +0200 Original-Received: from localhost ([::1]:60653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZE1f-0001aY-7n for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 04:13:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZE1a-0001Wi-I1 for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:13:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZE1X-0007Mq-7e for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:13:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZE1X-0007Md-4x for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:13:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZE1W-0006lw-IJ for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 08:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21432 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144169992325906 (code B ref 21432); Tue, 08 Sep 2015 08:13:02 +0000 Original-Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 08:12:03 +0000 Original-Received: from localhost ([127.0.0.1]:52151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZE0Z-0006jk-DZ for submit@debbugs.gnu.org; Tue, 08 Sep 2015 04:12:03 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:53743) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZE0W-0006jI-LP for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 04:12:01 -0400 Original-Received: from thinkpad-t440p (dhcp250.uni-koblenz.de [141.26.71.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 5E9FA3D6005; Tue, 8 Sep 2015 10:11:59 +0200 (CEST) In-Reply-To: <87wpw1uzd0.fsf@gmx.de> (Michael Albinus's message of "Tue, 08 Sep 2015 09:47:07 +0200") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106235 Archived-At: Michael Albinus writes: Hi Michael, >> 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. I guess the best solution was if >> `file-notify-rm-watch' never signaled an error (then the docs can >> stay as they are), and there would be some `file-notify-valid-p' >> predicate which would test if a given descriptor still denotes a >> valid file or directory. I guess the latter has probably some >> function equivalent in the respective backend APIs, and even if not, >> it can be implemented by inspecting `file-notify-descriptors'. > > `file-notify-rm-watch' is just a cleanup function, it's not worth to > add some error handling. I will wrap the call of the native handlers > by catching `file-notify-error'. Alternatively, `inotify-rm-watch' > could be adapted not to raise an error in this case. Great, thanks. > `file-notify-valid-p' is a nice idea; I will see how I could add it. > At least for the w32 case I would need some help from Eli, in order to > see whether the native library supports such a check. I just wanted to write that such a predicate would not strictly be needed because if one really cares, she could determine when a descriptor becomes invalid by handling all delete notifications. But that's not really true because when watching a directory, you only receive events for the contents of the directory, not for the directory itself. That is, if you want to receive notifications about changes to your watched directory itself, then you need to watch also its parent directory. Bye, Tassilo