From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 06:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 21432 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 21432@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.144169418316931 (code B ref -1); Tue, 08 Sep 2015 06:37:01 +0000 Received: (at submit) by debbugs.gnu.org; 8 Sep 2015 06:36:23 +0000 Received: from localhost ([127.0.0.1]:52073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZCVx-0004Oz-Mk for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34826) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZCVu-0004Oq-Cl for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZCVr-0004p7-Ed for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVr-0004p3-Bm for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVo-0000ZJ-DJ for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZCVk-0004nt-9a for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:12 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:50461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVj-0004nF-SG for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:08 -0400 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 DB3FA3D6005 for ; Tue, 8 Sep 2015 08:36:06 +0200 (CEST) From: Tassilo Horn Date: Tue, 08 Sep 2015 08:36:06 +0200 Message-ID: <87k2s15sfd.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Right now, (at least) the inotify version of `file-notify-rm-watch' signals an error in case the given descriptor denotes a directory which has been deleted in the meantime. If it denotes a file which has been deleted, no error is signaled. Here's a receipe: (require 'filenotify) (let* ((flags '(change)) (handler (lambda () nil)) (file (make-temp-file "foo")) (file-watch (file-notify-add-watch file flags handler)) (dir (make-temp-file "bar" t)) (dir-watch (file-notify-add-watch dir flags handler))) (delete-file file) (delete-directory dir) (file-notify-rm-watch file-watch) ;; works (message "Removed file watch") (file-notify-rm-watch dir-watch) ;; signals an error (message "Removed directory watch")) The documentation does not define any specific behavior for these situation, so this is currently a gray area which makes it hard for package developers to develop something which will work right accross the different notification backends. 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'. In GNU Emacs 25.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-09-08 Repository revision: 6cd64aaf1317bdd96f29fa2a7c3d49172e79bc37 Windowing system distributor 'The X.Org Foundation', version 11.0.11702000 System Description: Arch Linux Configured using: 'configure 'CFLAGS=-g -ggdb3 -O1'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LC_MONETARY: de_DE.utf8 value of $LC_NUMERIC: de_DE.utf8 value of $LC_TIME: de_DE.utf8 value of $LANG: en_US.utf8 locale-coding-system: utf-8-unix Major mode: Group Minor modes in effect: hl-line-mode: t gnus-topic-mode: t global-company-mode: t shell-dirtrack-mode: t global-aggressive-indent-mode: t gnus-undo-mode: t pdf-occur-global-minor-mode: t recentf-mode: t global-subword-mode: t subword-mode: t save-place-mode: t savehist-mode: t show-paren-mode: t ivy-mode: t minibuffer-depth-indicate-mode: t electric-pair-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent messages: 20150908T081715.611> Reading active file via nndraft... 20150908T081715.611> Reading active file via nndraft...done 20150908T081715.612> Reading active file from archive+nnml+archive:sent-postings via nnml... 20150908T081715.612> Opening nnml server on archive+nnml+archive:sent-postings... 20150908T081715.613> Opening nnml server on archive+nnml+archive:sent-postings...done 20150908T081715.615> nnml: Reading incoming mail (no new mail)...done 20150908T081715.615> Reading active file from archive+nnml+archive:sent-postings via nnml... 20150908T081715.616> Reading active file from archive+nnml+archive:sent-postings via nnml...done 20150908T081715.616> Checking new news...done Contacting host: debbugs.gnu.org:80 Load-path shadows: ~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath ~/Repos/el/highlight-symbol.el/highlight-symbol hides /home/horn/.emacs.d/elpa/highlight-symbol-20150816.628/highlight-symbol ~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4 ~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color ~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec ~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache ~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util ~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode ~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig ~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5 ~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm ~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def ~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104 ~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm ~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram ~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns ~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl ~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls ~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc ~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc ~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest ~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode ~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex ~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash ~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock ~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething ~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode ~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util ~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047 ~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml ~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus ~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range ~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int ~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud ~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat ~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh ~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl ~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify ~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar ~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway ~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums ~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse ~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt ~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap ~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft ~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source ~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat ~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3 ~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir ~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader ~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite ~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary ~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary ~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder ~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art ~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon ~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec ~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir ~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial ~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry ~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar ~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface ~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun ~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start ~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley ~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon ~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report ~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp ~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil ~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir ~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr ~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime ~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual ~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications ~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool ~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group ~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg ~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util ~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve ~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft ~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent ~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec ~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark ~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991 ~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231 ~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc ~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo ~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete ~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent ~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7 ~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree ~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu ~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml ~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve ~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus ~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml ~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message ~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime ~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform ~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent ~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic ~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern ~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc ~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage ~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode ~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls ~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired ~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl ~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox ~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win ~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async ~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url ~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html ~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi ~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015 ~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss ~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh ~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum ~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb ~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr ~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix ~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore ~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045 ~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg ~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash ~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score ~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu ~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam ~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view ~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode ~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text ~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems ~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry ~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source ~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar ~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill ~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils ~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap ~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay ~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies ~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive ~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843 ~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill ~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp ~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode ~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic ~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache ~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail ~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm ~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync ~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo ~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry ~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup ~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time ~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date Features: (shadow sort gnus-cite emacsbug sendmail mm-archive crm debbugs-gnu add-log debbugs soap-client url-http url-auth url-gw warnings hl-line nndraft nnmh rot13 utf-7 gnutls network-stream nsm starttls nnml nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg gnus-gravatar mail-extr gravatar gnus-topic nnir gnus-registry registry eieio-compat eieio-base th-private smex ido seq filenotify debug eieio-opt speedbar sb-image ezimage dframe colir color company-files company-oddmuse company-keywords company-etags company-gtags company-dabbrev-code company-dabbrev company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-css company-nxml company-bbdb company stratego-mode greql-mode tg-mode generic preview-latex tex-site auto-loads cider tramp-sh cider-debug cider-browse-ns cider-inspector cider-mode cider-repl cider-eldoc cider-interaction spinner arc-mode archive-mode cider-overlays cider-doc org-table org org-macro org-footnote org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs cider-test cider-stacktrace cider-client cider-util nrepl-client tramp tramp-compat tramp-loaddefs trampver shell pcomplete queue ewoc etags xref project dash clojure-mode paredit aggressive-indent epa-file epa epg rdictcc google-contacts-message google-contacts xml url-cache google-oauth google-contacts-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source password-cache url-vars mailcap nnheader gnus-util dired-x em-term term ehelp esh-opt esh-ext esh-util highlight-symbol thingatpt boxquote rect ecomplete message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-utils gmm-utils mailheader server yasnippet disp-table noutline outline pdf-occur ibuf-ext ibuffer tablist tablist-filter semantic/wisent/comp semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cconv eieio-core mode-local find-func cedet dired pdf-isearch let-alist pdf-misc imenu pdf-tools compile comint ansi-color cus-edit cus-start cus-load pdf-view bookmark pp jka-compr pdf-cache pdf-info tq pdf-util format-spec image-mode browse-kill-ring derived recentf tree-widget wid-edit highlight-parentheses cl iedit iedit-lib cl-extra help-mode hydra lv counsel swiper cap-words superword subword saveplace savehist paren ivy delsel icomplete mb-depth ace-window easy-mmode cl-macs gv avy ring smart-mode-line-respectful-theme smart-mode-line-light-theme cl-seq smart-mode-line rich-minority rx bs elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load subr-x pcase tsdh-light-theme finder-inf memory-usage-autoloads advice info package easymenu epg-config time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 639836 122215) (symbols 48 53035 0) (miscs 40 301 344) (strings 32 164700 67149) (string-bytes 1 5718922) (vectors 16 50490) (vector-slots 8 1133948 17525) (floats 8 961 537) (intervals 56 5318 0) (buffers 976 29) (heap 1024 83217 3736)) From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted In-Reply-To: <87k2s15sfd.fsf@gnu.org> Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 07:48: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: To: Tassilo Horn Cc: Eli Zaretskii , 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144169843523371 (code B ref 21432); Tue, 08 Sep 2015 07:48:02 +0000 Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 07:47:15 +0000 Received: from localhost ([127.0.0.1]:52107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZDcY-00064t-QB for submit@debbugs.gnu.org; Tue, 08 Sep 2015 03:47:15 -0400 Received: from mout.gmx.net ([212.227.17.22]:62726) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZDcW-00064e-Rd for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 03:47:13 -0400 Received: from detlef.gmx.de ([87.146.58.15]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MV1wf-1ZAIKW0T09-00YS0R; Tue, 08 Sep 2015 09:47:09 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> Date: Tue, 08 Sep 2015 09:47:07 +0200 Message-ID: <87wpw1uzd0.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:DLGYpA/t4ExNUcWyJMwAZcwUlddvLl64IFxNIYdyPeiI+83WimS 5OnwwfQOirPXOP6InQBQBM+LpKIkL5O77TrNph/kZs12a+sEW7pxKR94W1tVRfzJ07t28mW 1T0bbR+kEp7tFbsSnOnnksb3JEIuwviajfj9yyKoeqPZtYDXXQ54criXTRZxDVYvcPLdOAA iZ1h2VozJIqVvNrvzkkxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:BmKK0y1MLlU=:RtXRQV7gn39c3UxcB+lHbG 0e41pIhEJ9mrqxf6+NfaH0j4a+Y6dp1Iegumuts4yS7oidW4xCMc2/qoRX/uvVt5JEWl3dpLn 7TwTMlCTiCNNUSW7RZsStQZCNpgR+ZtbpMk5dQrVZpyVesABL5heGJhxNox032hAnYOZzYjub IJ9OyPn4YE8dGdI3J11e3SQWKo90uJFh7pTonaTQuQdm6CKFelCOtE+Z3Qpdi0J0h1O8NseHJ AT3cHzMethWcVpG+S0qR23jjoter8S/705P/sY8MRruzD0ZBZx2oGmB5DSTtBGDGuoeQUvBW5 4CKshexmXAx9X2Zg29TbYMkSVpI3qRAQF8PttNTDUdL+eaEAzlDnzgsO3q/WcT+DJ2mz2EE1S qFfe+qTZYvQWYhRvMCcvr7nxtg6I48A+sMda3YZcsc/SFzJUpusivaE9W0dZeI5Qc5releX9K y2n9ZNSJRwskAFzvehb7+Y10tMvD3H9H1B1TDv1M+1isiRm069CS7kbPM6nSufuIckNHqzJKH T0bVO3TmGIEpIDvZ0XyUAfSbJqNNXcXds9sRWEt6gIa0wNsvUlMp5qCibwZ8xU32FPzdwi/E4 6JO1o+sY6PumBg9YdurfXWAAOXVwRJ4+t0whISq53fhzuRRYBIlrUouOQncpQSlglejEE2K+/ gLtDb9RdViCwTSytCRTx0h2gdiss7fkGI69iM7SVGGu1PBKgoEIRRrYo3VqVfI6U5skf3mbmE VUT65IBKRdxeMD0eY5dbMDxXlfQh0PqUUUscww== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Tassilo Horn writes: Hi Tassilo, > 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. `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. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted 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: To: Michael Albinus Cc: Eli Zaretskii , 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144169992325906 (code B ref 21432); Tue, 08 Sep 2015 08:13:02 +0000 Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 08:12:03 +0000 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 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 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) From: Tassilo Horn References: <87k2s15sfd.fsf@gnu.org> <87wpw1uzd0.fsf@gmx.de> Date: Tue, 08 Sep 2015 10:11:59 +0200 In-Reply-To: <87wpw1uzd0.fsf@gmx.de> (Michael Albinus's message of "Tue, 08 Sep 2015 09:47:07 +0200") Message-ID: <8737yp5nzk.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) 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 From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 15:50:03 +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: To: Tassilo Horn Cc: 21432@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144172736710755 (code B ref 21432); Tue, 08 Sep 2015 15:50:03 +0000 Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 15:49:27 +0000 Received: from localhost ([127.0.0.1]:52815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZL9D-0002nO-7j for submit@debbugs.gnu.org; Tue, 08 Sep 2015 11:49:27 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:44425) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZL9A-0002nF-Mr for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 11:49:26 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NUD00H007Q47D00@mtaout25.012.net.il> for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 18:46:07 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD007Q67SVA8A0@mtaout25.012.net.il>; Tue, 08 Sep 2015 18:46:07 +0300 (IDT) Date: Tue, 08 Sep 2015 18:49:36 +0300 From: Eli Zaretskii In-reply-to: <87k2s15sfd.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83oahc7vxr.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Date: Tue, 08 Sep 2015 08:36:06 +0200 > > Right now, (at least) the inotify version of `file-notify-rm-watch' > signals an error in case the given descriptor denotes a directory which > has been deleted in the meantime. If it denotes a file which has been > deleted, no error is signaled. > > Here's a receipe: > > (require 'filenotify) > (let* ((flags '(change)) > (handler (lambda () nil)) > (file (make-temp-file "foo")) > (file-watch (file-notify-add-watch file flags handler)) > (dir (make-temp-file "bar" t)) > (dir-watch (file-notify-add-watch dir flags handler))) > (delete-file file) > (delete-directory dir) > (file-notify-rm-watch file-watch) ;; works > (message "Removed file watch") > (file-notify-rm-watch dir-watch) ;; signals an error > (message "Removed directory watch")) > > The documentation does not define any specific behavior for these > situation, so this is currently a gray area which makes it hard for > package developers to develop something which will work right accross > the different notification backends. > > 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. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 15:53: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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144172755211040 (code B ref 21432); Tue, 08 Sep 2015 15:53:02 +0000 Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 15:52:32 +0000 Received: from localhost ([127.0.0.1]:52819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLCB-0002s0-Oj for submit@debbugs.gnu.org; Tue, 08 Sep 2015 11:52:32 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:59593) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLCA-0002rs-87 for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 11:52:30 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NUD001007X2ZR00@a-mtaout20.012.net.il> for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 18:51:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD00151823LV90@a-mtaout20.012.net.il>; Tue, 08 Sep 2015 18:51:39 +0300 (IDT) Date: Tue, 08 Sep 2015 18:51:52 +0300 From: Eli Zaretskii In-reply-to: <87wpw1uzd0.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83mvww7vtz.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <87wpw1uzd0.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: 21432@debbugs.gnu.org, Eli Zaretskii > Date: Tue, 08 Sep 2015 09:47:07 +0200 > > `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. What happens on w32 when a watched directory is deleted is that the thread which watches the changes exits (with an abnormal status), but the object created to watch the changes still exists, and can be easily tested for being "invalid". So if you want to implement file-notify-valid-p, go ahead; the w32 side will be almost trivial. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 16:02:01 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, Tassilo Horn Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144172808411908 (code B ref 21432); Tue, 08 Sep 2015 16:02:01 +0000 Received: (at 21432) by debbugs.gnu.org; 8 Sep 2015 16:01:24 +0000 Received: from localhost ([127.0.0.1]:52827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLKm-000360-4D for submit@debbugs.gnu.org; Tue, 08 Sep 2015 12:01:24 -0400 Received: from mout.gmx.net ([212.227.15.15]:58874) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLKj-00035r-MM for 21432@debbugs.gnu.org; Tue, 08 Sep 2015 12:01:22 -0400 Received: from detlef.gmx.de ([87.146.58.15]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3j17-1YiTlR1IZ7-00rFhk; Tue, 08 Sep 2015 18:01:20 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> Date: Tue, 08 Sep 2015 18:01:18 +0200 In-Reply-To: <83oahc7vxr.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 18:49:36 +0300") Message-ID: <87lhcgvr1t.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:EVg2SNzDtUixhwRHbpxC+G7W/Y+eLtDght6mMc/l7On/lpUk3WR KBj1YHNC0bAeLxaBsdPgVPvcw+aAujmfv/zAqDnBWDWaHGiL98yaXVHqqd+apu+8035nit0 Vya7bVlgcy4jY11zDt9VQ1pScSCaJi8keOHJHOw7Yx5qqRzZcOmvTFBMc65nWtmUnj7it1J Fz9BNOdVQV03tfysNsmSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Wfu/p/glWYQ=:nuBF+6dIqZd6pyRDbFAd1y t7G2s/piVyQ3AploCVq7ReJGsoCvPF+rzGiSPZ+fSUELWHJbsCwO2n261imJ3LW6CMQHzYGx7 z9V0IEZwOi7kN+wl1ODroUUJAQKE7oOl4InAdDXvSRTb1GVxzRj7vjMoBrVOfyFh6s1gD8fRl PxMkJU5Eh25B4GJ4VKVEm0r9+6wv6OE46CllEcFlciRUNnpAnevARmXL8g7Vg0EJkn1xJOVb/ JnJFLYW6PEsPR+vZUHCx80cdiVgSYCyZK+8X81t6B6JIeKKUUghDdI77QYaogzEg/i4RA+w52 YYe2W/Uxbpsq5JN7WJiOop02uKzSC6L5JrTpY0NBYHq2s1VngHkGBB96h8xIa56vESDHihTBn IC0STpQq6ifik4PE1l3/ilW4RnuUGPaNIglZtFH2e0ChDDinGt/EQrLZHDM6Qxh7C7sD/FKsC PBwogCp8bULk6G0WUhNMnHfeiBIfUr8otq3R3jEfmtaHBjKphI/OfrsYrjcipKwtay4XB6boz e0+mNZA214/bQzENbUyOa+XNcQ6jw0Qiu5tZeyIBg1+FrbL05Ol6vda6KIKxtxrjS87KqKpXt ny3nXA7ZbcyUJZxk0xBC7f2pVNK7AlObrpxUKxPHN2kBN9f+g0dVQxA+pQwpewmMHU1/XKPfm XR8612Tk4iGZe9XFnZuC+UB5ml8hM/7sjVyqF4J8CxL2IiY4EXgJ39FpLxQZzjVhIbZfa3XOd BH591ynba3EwNIRqHq4hmrOmuqDIB9iGUP0hUQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii 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 quite when the native rm-watch fails seems to be appropriate. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Sep 2015 10:19:01 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, Tassilo Horn Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144205308621445 (code B ref 21432); Sat, 12 Sep 2015 10:19:01 +0000 Received: (at 21432) by debbugs.gnu.org; 12 Sep 2015 10:18:06 +0000 Received: from localhost ([127.0.0.1]:57651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zahsk-0005Zo-5V for submit@debbugs.gnu.org; Sat, 12 Sep 2015 06:18:06 -0400 Received: from mout.gmx.net ([212.227.15.15]:57017) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zahsh-0005Zg-QX for 21432@debbugs.gnu.org; Sat, 12 Sep 2015 06:18:04 -0400 Received: from detlef.gmx.de ([93.209.76.37]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LwqwS-1YYdyE1OJ6-016LO1; Sat, 12 Sep 2015 12:18:02 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> Date: Sat, 12 Sep 2015 12:18:01 +0200 In-Reply-To: <87lhcgvr1t.fsf@gmx.de> (Michael Albinus's message of "Tue, 08 Sep 2015 18:01:18 +0200") Message-ID: <87r3m4hrfq.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:230uvNrzxeFQQFM2N2u1TTukG10h3mG7+pTRDpQCG0TN3ETLxLP ke2R6wsmrDNRv1hUDq6Gu59v2B5G4nu7ENiDYgWSCRlrBFIY7faoCGGNN6VEa58+Qfjlhuv tNXdoLL8MKtt75JMJkNXtDFTRN4P65qlfqV6lah8wgqPXciFfkDuBdQgGrR944u3/wgvw/a yfk6Th4ssz0XIbt2qN0fQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:luWQ+/AprPM=:xgoUTtivzH753RIpEsu+6C W78wDz95hioCbr3XXA05WOIUoaySOC7ZLFltFdtniWt5jQl8iWlpBQv8De42CokMTE8dDPQSF O2TGkF0lrPFsXhbl3wjjuCrAwPreF1yFtJZ7s7KXDiz45iwdm1Xhl4cyZhMlkE/nyCYWp6id8 CFMi3Q3L5CLjwhayZbyCwIf1FFDd49Z8JMSNruTvAYltbtkfvElOrGO+B7G/vQRXXRm4452KE a9skUci+B4p8FsL0DnnS5Cz+EBR+Vmc8usxkG6Qhw3Ibg1R8V0opfKHtRmvuC/zPbML8quuO2 pYRfWYT+hxDusBYe5cTBH5o3KLd4x7qQqthUy+fEre2KfiRhoAVfaYd2QkfYjkAofy0gk7afM V1V+lswYbBYjokMbzHyKeAWaOOU7N00wQh9aAWH5eVzDwK1W9QJd18SuPd+ICf+iRKETRLErj eU2gGMwGBElA6hT40rgJuGMIEu3FmbjeoJ5nIFw+/FHG0xer7vGZKuR6oD/JcliaC4TyIUmjw 42ws+HtW/mTCD5SPtdNWSL1VjNxdxlPb/Kx9xsgbJey8b1BOPEqRS/eewmTKVinpakfyvVF3f HnUlyrUzna0zkVFq+UbOXMVj1bkwm6FYcymYIyHVPpdmqK85neJE0Yf8M5QUK9jIYRL4djfe0 HkA7DUwVvgoutnQtODfkp80Nycsf9qxOprWVYLF8nIxoUO+LG2MhxpIlSD4pPSJ/Zut42oxC5 7i1cDV70Gqto+IkPjtqsCwAzgQ3JXoBlEb4z0Q== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Michael Albinus writes: > Eli Zaretskii 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. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Sep 2015 15:12:01 +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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144207070620882 (code B ref 21432); Sat, 12 Sep 2015 15:12:01 +0000 Received: (at 21432) by debbugs.gnu.org; 12 Sep 2015 15:11:46 +0000 Received: from localhost ([127.0.0.1]:58484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZamSw-0005Qj-5H for submit@debbugs.gnu.org; Sat, 12 Sep 2015 11:11:46 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:43159) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZamSt-0005QZ-Nd for 21432@debbugs.gnu.org; Sat, 12 Sep 2015 11:11:44 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NUK00C00KV3MN00@mtaout28.012.net.il> for 21432@debbugs.gnu.org; Sat, 12 Sep 2015 18:11:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUK008JCKV3J230@mtaout28.012.net.il>; Sat, 12 Sep 2015 18:11:27 +0300 (IDT) Date: Sat, 12 Sep 2015 18:11:37 +0300 From: Eli Zaretskii In-reply-to: <87r3m4hrfq.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83fv2jbrkm.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: Tassilo Horn , 21432@debbugs.gnu.org > Date: Sat, 12 Sep 2015 12:18:01 +0200 > > Michael Albinus writes: > > > Eli Zaretskii 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. 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. > 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. > gfilenotify and w32notify do not seem to to care. In w32notify, I did that on purpose: it's not the business of the tail to wag the dog. Low-level functions has no business calling higher-level APIs on their own. > 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. > 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'?. Yes, it should. ('file-notify-error' didn't exist when I developed w32notify.c.) From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Sep 2015 18:10:03 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14420813973715 (code B ref 21432); Sat, 12 Sep 2015 18:10:03 +0000 Received: (at 21432) by debbugs.gnu.org; 12 Sep 2015 18:09:57 +0000 Received: from localhost ([127.0.0.1]:58547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZapFN-0000xr-3W for submit@debbugs.gnu.org; Sat, 12 Sep 2015 14:09:57 -0400 Received: from mout.gmx.net ([212.227.17.22]:58125) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZapFL-0000xk-EC for 21432@debbugs.gnu.org; Sat, 12 Sep 2015 14:09:55 -0400 Received: from detlef.gmx.de ([93.209.76.37]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lb90f-1YvOoa3fCr-00kiK9; Sat, 12 Sep 2015 20:09:54 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> Date: Sat, 12 Sep 2015 20:09:52 +0200 In-Reply-To: <83fv2jbrkm.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Sep 2015 18:11:37 +0300") Message-ID: <87zj0rh5lb.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:A2Q1G2N7/YRkaUNd6t7xnLA1923f2ohFakNY1W/E6wgpKZhq09w 08ehtrmjND2r6DFbQXPrNIf6lfME0yY/W1IqeWOCsDez+pz8VZO4beihYfaYt15Ap8R/kvF XbuWAkKrSnkvd4vLRujU84EMjHP/uDIUC1GwXD7Y/1Ew9sxOmjyOActE4dMjX7/EbBgEUow hPu6Ee78Wa9wi5GoK+pzA== X-UI-Out-Filterresults: notjunk:1;V01:K0:tTIcaAECXq4=:B3XnkkEO1AEP6y7QpkhHQE yFHmkIJBF4C3SY1QTdWYHdxFslSKcEJPWem0flNq/vcke8aMUAO9SWaCbltwYV8h1gOjI5WVM wNlQ65jfh+XluwLQBvS97E+C1hUs6Q3ih3lfzqn/1LJCJWhQJXpBS1oaIt17o5gMFH/Bu+xQw T5n1jdFxdGmDAd914Lzi8G+r5sqemYu/QBrswokV7l5Za44L+A0WjwW86ea2owyxrgMIG3V6W uUVZqkRlCFUu5shsFyd1e56066a4VBmcLX/YeVlWI0iT9MAHPjb1p1m//6q6lppvU/UZdeYVy DZnUkvpQyFguCF+0sBjucI4fqebJdeUPRQ0xmhMCTYtxCg+xW8fQvxJQpPrm2qnIksf0Ml/gW GcpRxMFguVHsjFeb0JFwZobdY9QLRYC6R//b8HjdMRnSva23eXYfVyETmYoI7e2eOAC07xzC/ Qo1bc6GMlHoo5qjIgPN+5LMCo5Wuq9R4bx17zPzayA0MD2hyA4296oEqunj/xRilb43vmPkyT bNuOdHEXKHlavWC6ooj4giSTvQV92qkw/fOjESFBf09hw/UxQFVtdbYQ/2dNmS0PtMk2wOEZ4 oVZoiO4Y72+fkTLuUySjy7MApkSohVbgnipW/XIZpGJFgYj/ASF91mQXb6i4Ff3EWs1grVT7r E3bo8ObJOk5qY5QRXxHza0I+LLGzDsdp0FFBaYfv+FOk8Wxz1X/mlen86Ps0nA4KWaSjEFotr RK1IAYE7u6ELaHcPkBdYWkHA8+gjxZ5dtdogZQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii 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. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Sep 2015 19:24:01 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144217223119922 (code B ref 21432); Sun, 13 Sep 2015 19:24:01 +0000 Received: (at 21432) by debbugs.gnu.org; 13 Sep 2015 19:23:51 +0000 Received: from localhost ([127.0.0.1]:59277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbCsQ-0005BF-HO for submit@debbugs.gnu.org; Sun, 13 Sep 2015 15:23:50 -0400 Received: from mout.gmx.net ([212.227.15.18]:60135) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbCsO-0005B5-GM for 21432@debbugs.gnu.org; Sun, 13 Sep 2015 15:23:49 -0400 Received: from detlef.gmx.de ([93.209.87.197]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRXzM-1ZCxtz2Kbo-00Sbgo; Sun, 13 Sep 2015 21:23:47 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> Date: Sun, 13 Sep 2015 21:23:46 +0200 In-Reply-To: <87zj0rh5lb.fsf@gmx.de> (Michael Albinus's message of "Sat, 12 Sep 2015 20:09:52 +0200") Message-ID: <87h9myt96l.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:ma86Htnbj2xsTbo78SmzLImFC0Jsg0sZWAMeZtHNkUJQaEDvc2I BZ/uk0TB2xx0SylwBU8H4DXXKaO+M5I8C9p+aE3duUKFmzC8JC2JmsbyoEdEcfxXoozp+oF QCWwd3GPxOL3eN1vR4dcIqTOs1ln1zMNVo71j0S/z8gGY8ZOFJPTQ8qZNIPUTyyrQBhx+Jf qQDKLDAUxptcrQTjQIWmQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:4V2JzvMo3KI=:XG3NRYwGVf6s2ZX1VnS3+f urB4jHC5FAr44jwEDGvsUrgMa//Ivdw2mHYmivfyXaVpmt8O4bWilO4jdmTFa0rZeisXKBy2T WO+/V3U6LyxJOPWwGtJ5pqMWd0jQjGQAODb5NqS2g3lMxaeCKc2aoKE8qBiXi3MQYBm55Y8aL 5Cg+MoWb9gG13MLUGexoJIRtauIv/abw+LN8NXml17EjXWfHGQk+ZBDqUACyKYmg81i6ZzNut 2xvF9sNhHNAQpJiCuMjgrwwDMMaup7hpSOkz0pBdAfOsa38jFNQTfcGkigPIWBJvhDcf+KbXP CMquBSCcRGryyeDOrvAyeuMAMF1ttkrMBttDg7dffJeqMHXbcf0GjPFB5f9j5HLRHhtx+w6ox 6qIxyOJnFgOX//acFq4WkyPGbipXtJmjFU6uSW1+Qs9TTIJzem7dF98/hXSYbC7mZ7ZjCih7k 5f+0//nFDbvcfcl/yiMcs7LOHT+IrhEj3SP2fZrCyHWy6BguoeByoGibDSLjYt3Xgk4cKqI9j MtsJhT5WAFVOAS+Cw0cJi9OtFRaaTgcfnNBTczf/L+xgHQf1U6jj4RDl86XFJ6XKIH5Bq4iQG DzY0TsiY4TG6Dz2DfF7o2nnh3IRtLA1rF7ltaFm8LYxZdtIuD112tqZbzDGb2qrfPNitaMARx ySDGyL4Y9pEL+gTctB0aV7r9px+rlhR18xi00UI+6/k+whXYvRNSSlBtPQ4M5+Ix9j/SGXClu 393+iY+xo5zdOjfrPxJRwd9qqoieXu8fODPzCQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Michael Albinus writes: >> 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 :-( ) I've committed a patch to the trunk, adding `file-notify-valid-p' and its native implementations in inotify.c and tramp.el. Comments welcome. I know, documentation in the elisp manual is missing. I'll add it later, and also the native implementation in gfilenotify.c. Test cases, anywhere? Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 06:09: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: To: Michael Albinus Cc: Eli Zaretskii , 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221090812491 (code B ref 21432); Mon, 14 Sep 2015 06:09:02 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 06:08:28 +0000 Received: from localhost ([127.0.0.1]:59453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbMwF-0003FP-KL for submit@debbugs.gnu.org; Mon, 14 Sep 2015 02:08:27 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:53061) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbMwC-0003FG-LX for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 02:08:25 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 479DC20565 for <21432@debbugs.gnu.org>; Mon, 14 Sep 2015 02:08:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 14 Sep 2015 02:08:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=t3Sd9omWwHlRfBPX3nlLz63UmK8=; b=cTaN+ pRHjFl/wjgFvGbXfZZQI46JdTnWnRRv31IGwa27vB7NYZOd97OoLqEgmCB+WGgee /0Na00V4pBCEy9Io+FAtnisl6zK15cYg6gEN+RIcP3y9YKkWdtG+gLG9oDKByI33 3La68XllxasTJ53cJxXRdlmAFRBR096ZaDf/Vk= X-Sasl-enc: 3SjlcsEuIeD1kl+HOddvDsXgq11Q83sEj4ZCvZnsLQbY 1442210903 Received: from thinkpad-t440p (unknown [2.162.81.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 19E54C00014; Mon, 14 Sep 2015 02:08:22 -0400 (EDT) From: Tassilo Horn References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> Date: Mon, 14 Sep 2015 08:08:20 +0200 In-Reply-To: <87h9myt96l.fsf@gmx.de> (Michael Albinus's message of "Sun, 13 Sep 2015 21:23:46 +0200") Message-ID: <87zj0pild7.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Michael Albinus writes: Hi Michael, >>> 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 :-( ) > > I've committed a patch to the trunk, adding `file-notify-valid-p' and > its native implementations in inotify.c and tramp.el. Comments > welcome. > > I know, documentation in the elisp manual is missing. I'll add it > later, and also the native implementation in gfilenotify.c. > > Test cases, anywhere? I've added two tests, one for plain files and one for directories. They are "green" right now but I think they should not. What seems wrong to me is that the descriptors stay valid even when the watched file or directory is deleted. For files this might be ok (though maybe inotify-specific) because when I create a new file with the same name, the watch will trigger. However, the current hehavior is certainly wrong for directories. When I deleted the watched directory, the descriptor is still valid, but calling file-notify-rm-watch on it signals an error. Bye, Tassilo From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 07:10:03 +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: To: Tassilo Horn Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221456317672 (code B ref 21432); Mon, 14 Sep 2015 07:10:03 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 07:09:23 +0000 Received: from localhost ([127.0.0.1]:59479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbNtC-0004ax-Qc for submit@debbugs.gnu.org; Mon, 14 Sep 2015 03:09:23 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:37572) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbNt9-0004ao-Fp for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 03:09:20 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUN00E00NMDVN00@mtaout27.012.net.il> for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 10:05:24 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUN00AYNNP0IJ40@mtaout27.012.net.il>; Mon, 14 Sep 2015 10:05:24 +0300 (IDT) Date: Mon, 14 Sep 2015 10:08:50 +0300 From: Eli Zaretskii In-reply-to: <87zj0pild7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83oah5a35p.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: Eli Zaretskii , 21432@debbugs.gnu.org > Date: Mon, 14 Sep 2015 08:08:20 +0200 > > Michael Albinus writes: > > Hi Michael, > > >>> 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 :-( ) > > > > I've committed a patch to the trunk, adding `file-notify-valid-p' and > > its native implementations in inotify.c and tramp.el. Comments > > welcome. I've added a w32 implementation in w32notify.c. > I've added two tests, one for plain files and one for directories. They > are "green" right now but I think they should not. I think you are testing this incorrectly. > What seems wrong to me is that the descriptors stay valid even when the > watched file or directory is deleted. For files this might be ok > (though maybe inotify-specific) because when I create a new file with > the same name, the watch will trigger. > > However, the current hehavior is certainly wrong for directories. When > I deleted the watched directory, the descriptor is still valid, but > calling file-notify-rm-watch on it signals an error. AFAIR, filenotify.el watches the parent directory of the file/directory you asked it to watch. So to see the invalid-p method in action you need to remove the parent, not the directory itself. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 07:36: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: To: michael.albinus@gmx.de Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221613820019 (code B ref 21432); Mon, 14 Sep 2015 07:36:02 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 07:35:38 +0000 Received: from localhost ([127.0.0.1]:59485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOIb-0005Co-OM for submit@debbugs.gnu.org; Mon, 14 Sep 2015 03:35:38 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:60977) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOIW-0005Cc-6Y for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 03:35:33 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NUN00F00OBWCP00@mtaout25.012.net.il> for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 10:32:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUN00AQIOXX0060@mtaout25.012.net.il>; Mon, 14 Sep 2015 10:32:21 +0300 (IDT) Date: Mon, 14 Sep 2015 10:35:28 +0300 From: Eli Zaretskii In-reply-to: <83fv2jbrkm.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83mvwpa1xb.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 12 Sep 2015 18:11:37 +0300 > From: Eli Zaretskii > Cc: 21432@debbugs.gnu.org, tsdh@gnu.org > > > 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'?. > > Yes, it should. I've done that now. I find the way inotify.c and gfilenotify.c report errors suboptimal: they don't report the errno value and the related data, so the error messages tell less than they could. I went the way similar to report_file_error instead. Maybe the other back-ends should follow suit. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 07:38: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221627020207 (code B ref 21432); Mon, 14 Sep 2015 07:38:02 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 07:37:50 +0000 Received: from localhost ([127.0.0.1]:59489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOKj-0005Fr-SW for submit@debbugs.gnu.org; Mon, 14 Sep 2015 03:37:50 -0400 Received: from mout.gmx.net ([212.227.17.20]:57694) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOKh-0005Fi-HB for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 03:37:48 -0400 Received: from detlef.gmx.de ([87.146.33.99]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lkjuq-1Z1Eha05MS-00aUBw; Mon, 14 Sep 2015 09:37:46 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <83mvwpa1xb.fsf@gnu.org> Date: Mon, 14 Sep 2015 09:37:44 +0200 In-Reply-To: <83mvwpa1xb.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 10:35:28 +0300") Message-ID: <87zj0psb7b.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:cAvPKAWRrk9uaEXVQ4Lhm+sLimQXy5x2hoh2uwY50eRBHjD5ALg FFnks2BlwayLPiVHBsSr0XHUitMYVr6llotlTiX3KHw9PiXmuprGw31JmSO7zExn7JsJaXp bUfD2qfKt2lhp5oRd6f1Jpo3K49PpIS9FRa/7/uT2Rzd3+r5xDmnqIiSy8zthm7q1f8v1v8 WXbu2DchljJqKm4IDy88A== X-UI-Out-Filterresults: notjunk:1;V01:K0:5pNWQ6/KfPQ=:jDUUKKqxMNEojFbBoR7Tda R14PXU2G8Tqke4RjrmZMspbQPCa3QSuAvzdlDhDDiYuzertulecQn7RDeX+MeVvNudtPohvaU xRwJTKkZmb5T4FD5grjJGAXEkFZwJD/4Yq37KUe9Wi3TsYXgHsYDzrvcXs7knLh1sRzJhU0EO wue55RvrLnfBAKAobAHP/PIGxCIYRBjB+tNnFphghHzJa0XjeJDLYZqt1h+qmsa/sUL8Uc90Z JEZIhYuCZ47Jnwiu6Hbx2Kfc9b1HVOvLTi3qETPEhqqhtxAbvn6GfKSGfkzXOwIyklXgzIniC TCiTySyuB1n/HP+XiW5OKzr6hmTks8ByI45PRzjm7ZSVkK7XhPsjoxYKBzLnXJTjBFY3zoqQO 39QV4/C2snFjUV9EuVLNF4DcoIS6yij91d+NTO5kMgQAJZGjQkxEUGCz7gxiUl/i0xrY/Qb4O z6iDCLapzWZhC0c7hXqcYKVjZADSrbZ4VUExqal397gvjaTKf8/58nkhZXEyr4tsajO5Fu1NW tib4SLiD3S4JBPv8bc7OZWGycZ9n05++ntAX1+4xjfQmizlgo4kMvKkFRpCLsGbQ/R4WOQlEH j2W0vHj4GRaIAbc+U2kft3UZMg7AF7OyndomXpvolX+smwn+pUFGgvRYd5fGlxPgCZEnzGiFq ROXqi+sb465sWWXYfqsqRqaxwISmOgfNe6Owf/EkxZbdBSA5r0JMZ9D9EvCFWdgS7UdoAQJw/ NaMo9EaObjP1XAyfXbvi1VCU3wIyAPGAm2tQww== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > I find the way inotify.c and gfilenotify.c report errors suboptimal: > they don't report the errno value and the related data, so the error > messages tell less than they could. I went the way similar to > report_file_error instead. Maybe the other back-ends should follow > suit. Will do. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 07:41:01 +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: To: Eli Zaretskii Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221642620441 (code B ref 21432); Mon, 14 Sep 2015 07:41:01 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 07:40:26 +0000 Received: from localhost ([127.0.0.1]:59493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbONF-0005Jd-It for submit@debbugs.gnu.org; Mon, 14 Sep 2015 03:40:25 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:51139) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbONE-0005JV-0o for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 03:40:24 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 653E020951 for <21432@debbugs.gnu.org>; Mon, 14 Sep 2015 03:40:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 14 Sep 2015 03:40:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=JR+CPemo1MX79P8jQ3+oaw6VSV0=; b=POv47 gR0kNv3EuqhOJqhQZsPfjXEmM5ESCdgHfymlWAILOJlZKBDa2Bd09qOIRHIIayYq Oz9PsT5zxh10MKK4wrrOOHxoawM8vB+pa92EzJhqKVeLb0sf33mpnv/Qeju3zxhm pXrdrUnvBWDlTugnsMgbBIpeOXFfg1K8SRSf1A= X-Sasl-enc: 7amuMBDZNC8hx/Zv3YVAw9Y7Uw0gjeZw8qonGGXgYW7R 1442216422 Received: from thinkpad-t440p (unknown [2.162.81.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 41471C00014; Mon, 14 Sep 2015 03:40:22 -0400 (EDT) From: Tassilo Horn References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> Date: Mon, 14 Sep 2015 09:40:19 +0200 In-Reply-To: <83oah5a35p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 10:08:50 +0300") Message-ID: <87vbbdih3w.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: >> What seems wrong to me is that the descriptors stay valid even when >> the watched file or directory is deleted. For files this might be ok >> (though maybe inotify-specific) because when I create a new file with >> the same name, the watch will trigger. >> >> However, the current hehavior is certainly wrong for directories. >> When I deleted the watched directory, the descriptor is still valid, >> but calling file-notify-rm-watch on it signals an error. > > AFAIR, filenotify.el watches the parent directory of the > file/directory you asked it to watch. So to see the invalid-p method > in action you need to remove the parent, not the directory itself. Ah, I see. I'll adapt the tests accordingly. Bye, Tassilo From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 07:57:01 +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: To: Eli Zaretskii Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144221737921767 (code B ref 21432); Mon, 14 Sep 2015 07:57:01 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 07:56:19 +0000 Received: from localhost ([127.0.0.1]:59499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOcd-0005f1-6I for submit@debbugs.gnu.org; Mon, 14 Sep 2015 03:56:19 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:50074) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbOca-0005et-LE for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 03:56:17 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 66943206BE for <21432@debbugs.gnu.org>; Mon, 14 Sep 2015 03:56:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 14 Sep 2015 03:56:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=yYYXj/Q4N2A8D7VCLHo86w40raI=; b=hVqG9 nPOsJ8w7+lsS+0OS2MTmSHZOsM4zIG6UZGYhi5wwIyOTe2PzhcL1ex8F0FeAEfUZ SkosVsw9aU5tm7Z6DFN4dbnVmh5K5FmEPlDs2Bmo4EyKfwa8u60B593KocqBJKc0 a+JO9xUWCnOvIxPcN9NCGy4EJhRkrdS8SeAIPA= X-Sasl-enc: ec4vFZ9cX6jSx4gd7vuRF9FuQBLxPwEvH/1ux7cGK64X 1442217375 Received: from thinkpad-t440p (unknown [2.162.81.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 61E5AC00016; Mon, 14 Sep 2015 03:56:15 -0400 (EDT) From: Tassilo Horn References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> Date: Mon, 14 Sep 2015 09:56:12 +0200 In-Reply-To: <87vbbdih3w.fsf@gnu.org> (Tassilo Horn's message of "Mon, 14 Sep 2015 09:40:19 +0200") Message-ID: <87r3m1igdf.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Tassilo Horn writes: >>> What seems wrong to me is that the descriptors stay valid even when >>> the watched file or directory is deleted. For files this might be >>> ok (though maybe inotify-specific) because when I create a new file >>> with the same name, the watch will trigger. >>> >>> However, the current hehavior is certainly wrong for directories. >>> When I deleted the watched directory, the descriptor is still valid, >>> but calling file-notify-rm-watch on it signals an error. >> >> AFAIR, filenotify.el watches the parent directory of the >> file/directory you asked it to watch. So to see the invalid-p method >> in action you need to remove the parent, not the directory itself. > > Ah, I see. I'll adapt the tests accordingly. Done, however the descriptors still don't become invalid when deleting the parent directory of the watched file or directory. I guess, that's a problem in the inotify and TRAMP implementations then. Bye, Tassilo From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 13:23: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: To: Tassilo Horn Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144223696323406 (code B ref 21432); Mon, 14 Sep 2015 13:23:02 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 13:22:43 +0000 Received: from localhost ([127.0.0.1]:59748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbTiV-00065S-6e for submit@debbugs.gnu.org; Mon, 14 Sep 2015 09:22:43 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:34580) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbTiS-00065I-MN for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 09:22:42 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NUO0080051VY000@mtaout29.012.net.il> for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 16:23:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUO0086H56KHZ10@mtaout29.012.net.il>; Mon, 14 Sep 2015 16:23:08 +0300 (IDT) Date: Mon, 14 Sep 2015 16:22:38 +0300 From: Eli Zaretskii In-reply-to: <87r3m1igdf.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <837fnt9lup.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org > Date: Mon, 14 Sep 2015 09:56:12 +0200 > > >> AFAIR, filenotify.el watches the parent directory of the > >> file/directory you asked it to watch. So to see the invalid-p method > >> in action you need to remove the parent, not the directory itself. > > > > Ah, I see. I'll adapt the tests accordingly. > > Done, however the descriptors still don't become invalid when deleting > the parent directory of the watched file or directory. I guess, that's > a problem in the inotify and TRAMP implementations then. No, I think it's a problem with our mental model of what happens. The file notifications use the Emacs event loop, and Emacs won't check for events until it's idle. So calling file-notify-valid-p as part of the test ends up doing that _before_ the directory deletion notification is read by Emacs and invalidates the watch. I actually see the message saying the watch is valid before the notification comes in and its message is inserted into *Messages*. The following simple test case works with w32notify: (setq mydir "/tmp/x") (make-directory mydir t) (setq myfile "/tmp/x/y") (write-region "foo\n" nil myfile) (setq w (w32notify-add-watch mydir '(file-name attributes size last-write-time) (lambda (event) (message "%s" event)))) (message "valid: %s" (w32notify-valid-p w)) (delete-directory mydir t) (run-with-idle-timer 1 nil (lambda () (message "valid: %s" (w32notify-valid-p w)))) When I run the above snippet with eval-region, I see these messages in *Messages*: Wrote d:/tmp/x/y valid: t (100161480 modified y) (100161480 removed y) valid: nil Try something similar with inotify and see if you see the same basic issue. If you do, I trust you will think of a way to modify the tests so that validation does do its thing. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 20:24: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, Tassilo Horn Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14422622214869 (code B ref 21432); Mon, 14 Sep 2015 20:24:02 +0000 Received: (at 21432) by debbugs.gnu.org; 14 Sep 2015 20:23:41 +0000 Received: from localhost ([127.0.0.1]:60602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbaHs-0001GT-Up for submit@debbugs.gnu.org; Mon, 14 Sep 2015 16:23:41 -0400 Received: from mout.gmx.net ([212.227.15.18]:53069) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbaHq-0001GL-VE for 21432@debbugs.gnu.org; Mon, 14 Sep 2015 16:23:39 -0400 Received: from detlef.gmx.de ([87.146.33.99]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Le5XQ-1YqOVp2wai-00pvmF; Mon, 14 Sep 2015 22:23:37 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> Date: Mon, 14 Sep 2015 22:23:36 +0200 In-Reply-To: <837fnt9lup.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 16:22:38 +0300") Message-ID: <87mvwoycl3.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:6vx+/kCw9nJQwh4y6YZcildutiAw+Mjxl8yvP0QYEpeqC8kblnr QaFrdIDoZyNpUacqfSsbj3kBtnrZtrMrD43jJXdbf0UwVAqFBQSxN9uNVIzMKTgYgNQwO/8 QaSeOnS0upt+STtkUIFyEkdrruQyNXGdg5YLItv+LDJ/rVF/0N+mvBFqUhgDRnl5Fj0A3d4 3y3EkEfOGzd3eYZYQoiXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kBJGOlI2NUg=:p1l76Gl+2JM56J0p0pVDZu fWwm7/n0/Pmjnz+VMhtkAH3E+3o3KvDTwIPry4V0/iTaonbX38g4RW/dKdEoDp4hQSOMDbIvA BcMRyS/iIBKWk2pUAkBPjdb4fxdpubKZ3UsicJXEwR/HngFxsH5BeFb8PN6Tz8AxoingBsevN pMNA2eSUDUd0mGblwY2W2wYL11G2a1rKviUC8zYhALTxJ7ve3Ju8VvFjEGa0nmKYh9y7v0Q45 LNOWnvIJWkKhCs0bX5ejJ3n7qr4go+t8HU4/0W266DbZwtlLYGOrL1sGByyfMqcbpYvXOOQCY ixe2NwWejc3FqSYr6xDk0WhQRN5GyKUePh7a2uPUcX22uXElm5F6xDfmP/637rJlylJPnGw4t yV5LUhB60QKRxEQreheQKgl7bti0mIl3H9cxyU0gwozagAT7fjPGUhu5j9GWToq245VXSLFZD qOBZ4yGVS9eOUcuDI7C4v4BjGGNJJL/vnPd9Obh3q/cSnkOiz60OxPA6PojmXRZv21AAevLUX GxxbSy/lCSw/odApMB/H3K2i9fpoMhpCDqaEIHbPjvMeXWrQIEaTxVNHmU3EL7HXJIgH30Pxm /2PJcs4cnOun17BNMFAWHYwye2ecRpirepltPl/lsVkSF8/ncw4LIl+rp2sl/4KaaGDNj/Hqb dL9Osiyw9Iu9GaiZjIop/Di0m2z1XYNBI5wnS3ySBsf5rTN/asPZ+2oZwvPGWRMUBfyjl+DDq ruyWj7YpSYqjdbqkoqAjq/KoVAEaGXI5q/hiXQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > No, I think it's a problem with our mental model of what happens. The > file notifications use the Emacs event loop, and Emacs won't check for > events until it's idle. So calling file-notify-valid-p as part of the > test ends up doing that _before_ the directory deletion notification > is read by Emacs and invalidates the watch. I actually see the > message saying the watch is valid before the notification comes in and > its message is inserted into *Messages*. > > Try something similar with inotify and see if you see the same basic > issue. If you do, I trust you will think of a way to modify the tests > so that validation does do its thing. I've adapted `file-notify-test04-file-validity' and `file-notify-test05-dir-validity', and they pass the tests now for the inotify case. Hopefully, it is the same for w32notify. Implementation for gfilenotify and Tramp will follow. While being there, I have made also `file-notify-rm-watch' more robust by ignoring all `file-notify-error's. This was the initial trigger for bug#21432. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 05:54: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: To: Eli Zaretskii Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144229641924351 (code B ref 21432); Tue, 15 Sep 2015 05:54:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 05:53:39 +0000 Received: from localhost ([127.0.0.1]:60788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbjBS-0006Kh-El for submit@debbugs.gnu.org; Tue, 15 Sep 2015 01:53:38 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:57777) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbjBP-0006KY-Px for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 01:53:36 -0400 Received: from thinkpad-t440p (dhcp23.uni-koblenz.de [141.26.71.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 0CE441A8332; Tue, 15 Sep 2015 07:53:34 +0200 (CEST) From: Tassilo Horn References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> Date: Tue, 15 Sep 2015 07:53:34 +0200 In-Reply-To: <837fnt9lup.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 16:22:38 +0300") Message-ID: <87a8sout29.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii writes: >> Done, however the descriptors still don't become invalid when >> deleting the parent directory of the watched file or directory. I >> guess, that's a problem in the inotify and TRAMP implementations >> then. > > No, I think it's a problem with our mental model of what happens. The > file notifications use the Emacs event loop, and Emacs won't check for > events until it's idle. So calling file-notify-valid-p as part of the > test ends up doing that _before_ the directory deletion notification > is read by Emacs and invalidates the watch. Yes, you are right. Michael already fixed the tests by waiting for the file notifications before calling `file-notify-valid-p' and then we get the expected results (well, not yet with remote files). Bye, Tassilo From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 07:39:01 +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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14423027321363 (code B ref 21432); Tue, 15 Sep 2015 07:39:01 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 07:38:52 +0000 Received: from localhost ([127.0.0.1]:60853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbkpH-0000Lu-MS for submit@debbugs.gnu.org; Tue, 15 Sep 2015 03:38:52 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:45052) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbkpD-0000Lk-Oy for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 03:38:48 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NUP00900JV3L000@mtaout28.012.net.il> for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 10:38:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUP007UWJW5YB10@mtaout28.012.net.il>; Tue, 15 Sep 2015 10:38:29 +0300 (IDT) Date: Tue, 15 Sep 2015 10:38:46 +0300 From: Eli Zaretskii In-reply-to: <87mvwoycl3.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83mvwo873t.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: Tassilo Horn , 21432@debbugs.gnu.org > Date: Mon, 14 Sep 2015 22:23:36 +0200 > > I've adapted `file-notify-test04-file-validity' and > `file-notify-test05-dir-validity', and they pass the tests now for the > inotify case. Hopefully, it is the same for w32notify. No, it fails: Test file-notify-test04-file-validity condition: (ert-test-failed ((should (equal '... (mapcar ... events))) :form (equal (created changed deleted) nil) :value nil :explanation (different-types (created changed deleted) nil))) FAILED 9/12 file-notify-test04-file-validity I guess the file-notify--test-with-events macro doesn't allow events to come in on w32, but I have no idea how to debug this. Moreover, file-notify-test05-dir-validity also fails: Test file-notify-test05-dir-validity condition: (ert-test-failed ((should-not (file-notify-valid-p file-notify--test-desc)) :form (file-notify-valid-p 91670672) :value t)) FAILED 11/12 file-notify-test05-dir-validity The latter could be because of the batch mode (it passes when I invoke it interactively). But the former fails in interactive session as well, so it's a real problem. Suggestions for debugging it are welcome. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 08:01: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14423040163244 (code B ref 21432); Tue, 15 Sep 2015 08:01:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 08:00:16 +0000 Received: from localhost ([127.0.0.1]:60857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZblA0-0000qG-4p for submit@debbugs.gnu.org; Tue, 15 Sep 2015 04:00:16 -0400 Received: from mout.gmx.net ([212.227.15.19]:59595) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbl9x-0000q7-SE for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 04:00:14 -0400 Received: from detlef.gmx.de ([93.209.81.17]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lp3x6-1YwudT3sBg-00ewDG; Tue, 15 Sep 2015 10:00:12 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> Date: Tue, 15 Sep 2015 10:00:10 +0200 In-Reply-To: <83mvwo873t.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 10:38:46 +0300") Message-ID: <87bnd4xgc5.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:e8GC0BP6YWFoxj0DiYy0ouND3RyL4GcWysMiSzt33ecsZtt3A8q 2FHkmdR1vlL30UXFt8FQuVPw5OLmIbjJTOSE+pdKvbvuKNEjwfI3Xz41rBmaRTTbjKz/OY/ oY77+rBAh58JVSK115nyn+Gwj/sm06LSMgCkEQ+9H3GUHOdyHTh6NINMv30pFn4zsElVASG HkouN61zdppvwYZBNpVjw== X-UI-Out-Filterresults: notjunk:1;V01:K0:D25Q/1FcTj0=:po45OD5ybEW4e5ON2TnZ67 LveRwq/ETSgD2d15G953gSF5MpTfgr5W/0MYJ26fjyhfEpDGEbIhBEVpP68/MVH1D4kTseUqM jLXzlNQcxlWVx1kc59WQ4QXZGAjy1icwAbGmWq+ZJSCEAp0MQ82vH41tOrnXB1bsf57XalJHs i4UAgxbTDWOkNyfCp6rwYBueTNuL7rKIojiwB09enhlKA37y9ikAxHbsa3WFjpy5qD5cSLOq8 qM5PoN+Zef8thM1gApwDthG6RQ9X2htt9+GhxnK4zSByIOdwSA+QN3eYlubd4INygQg/c4niT imjByWq0p6G/6h01YQzFKkJwE4+mQxa+S4bgHX+M+xqDZRmtAlUUK5dsek4SPRnb6DnewoBGE Zx9KpP6nsEC9wlHOKIdXlYRznd1iLXTQMti8IiDYl7VUcCq+C2Jes12MzHrWO6UFxwZOJz6p9 i92YnTUCS9h8yIKXSf2aOkYZ+ScYRqLUNO3CAAmPMo9M7adflGewFZ8ncVI7nUJDGjKjokCjS fPTVDzUszNzzl+TQOi1hvNHmU/Cx7yEoxRHv2yZDYJKBDS1as2F8chQvUlkCwajk1HyWq9GrB ZG7dU3zlMfpeio+fOHIR3b9qMVFYsNicIidysWEZYt2e4q222IwjF+Jhf+7vq8tM4Gi/YG2M/ u+7t/V35Ar8kILLAW5IQ8Eo0meCeY7RzngEzi12G6HvE9W6v7tktMyXEhps71NdEJXANUleNr XLnmZ/Pktdm2TrCCpseDkLVn4Y9SFkfjfrnhww== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> I've adapted `file-notify-test04-file-validity' and >> `file-notify-test05-dir-validity', and they pass the tests now for the >> inotify case. Hopefully, it is the same for w32notify. > > No, it fails: > > Test file-notify-test04-file-validity condition: > (ert-test-failed > ((should > (equal '... > (mapcar ... events))) > :form > (equal > (created changed deleted) > nil) > :value nil :explanation > (different-types > (created changed deleted) > nil))) > FAILED 9/12 file-notify-test04-file-validity > > I guess the file-notify--test-with-events macro doesn't allow events > to come in on w32, but I have no idea how to debug this. After loading file-notify-tests.el, trace-function for file-notify-handle-event, file-notify-callback, file-notify--test-event-handler. Run only file-notify-test04-file-validity. Show the trace buffer. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 08:24: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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14423053945169 (code B ref 21432); Tue, 15 Sep 2015 08:24:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 08:23:14 +0000 Received: from localhost ([127.0.0.1]:60863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZblWD-0001LJ-MC for submit@debbugs.gnu.org; Tue, 15 Sep 2015 04:23:13 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:42597) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZblWB-0001L9-2U for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 04:23:12 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NUP00F00LVI3500@a-mtaout20.012.net.il> for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 11:22:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUP00EBNLXRJKA0@a-mtaout20.012.net.il>; Tue, 15 Sep 2015 11:22:40 +0300 (IDT) Date: Tue, 15 Sep 2015 11:22:40 +0300 From: Eli Zaretskii In-reply-to: <87bnd4xgc5.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83lhc8852n.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: tsdh@gnu.org, 21432@debbugs.gnu.org > Date: Tue, 15 Sep 2015 10:00:10 +0200 > > > I guess the file-notify--test-with-events macro doesn't allow events > > to come in on w32, but I have no idea how to debug this. > > After loading file-notify-tests.el, trace-function for > file-notify-handle-event, file-notify-callback, > file-notify--test-event-handler. Run only file-notify-test04-file-validity. > Show the trace buffer. Here: ====================================================================== 1 -> (file-notify-handle-event (file-notify (100272320 added ".#-emacsa05420") file-notify-callback)) | 2 -> (file-notify-callback (100272320 added ".#-emacsa05420")) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100272320 modified ".#-emacsa05420") file-notify-callback)) | 2 -> (file-notify-callback (100272320 modified ".#-emacsa05420")) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil I'm confused: why does it mention a lock file instead of some file in temporary-file-directory? Is some variable missing a value? From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 11:55: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14423180544245 (code B ref 21432); Tue, 15 Sep 2015 11:55:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 11:54:14 +0000 Received: from localhost ([127.0.0.1]:32774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbooP-00016O-0M for submit@debbugs.gnu.org; Tue, 15 Sep 2015 07:54:13 -0400 Received: from mout.gmx.net ([212.227.15.19]:63908) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbooN-00016G-5w for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 07:54:12 -0400 Received: from detlef.gmx.de ([93.209.81.17]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lh7PL-1YrWti0oOV-00oXst; Tue, 15 Sep 2015 13:54:09 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> Date: Tue, 15 Sep 2015 13:54:08 +0200 In-Reply-To: <83lhc8852n.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 11:22:40 +0300") Message-ID: <87zj0nx5i7.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:jBz6C50CoMdTAJARQansG0Zu6PrcyPIUj2xMds0b/8RifS8gjwv mri7aTFN8pQOo/XKmiaOr/uv/vS9/mfC5oT738ZSHIIH1bxpfBBdPxymIwojxmbtmGbtmnB BwpHruh4n5aX4iai+u7cGHnRc0Nc0THr4pGD0jv+UXDXIvEIwvJq4sfYMC3Bv7n74rU6ViA fDWV21sUMA5c/O9APWkRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xGp4ylgUG2k=:E24Tg6zMMv0Nf7/+XoMuSh chZtUY1OVKZiOCpCE1+G9pbTWFLEFOs7vr/Qbj6o2r23SrLt7Lb1PapynEocJpO1BGbQ3kU+3 d7G37xghXjicJ66YYgGxk0maiWBiLaXVzlO/S+LxW0DOr6ppEHO2JsaMmdgq/SyYsS8nYH++/ rPpYJ5zHzo402P38q448pKIN0rbyKV0o9l8dE80hF45UiYgnxmWedLvEqrZOdziSOt+UKaTHF T+WzxKYlX6l+mCAPKFY6CMeEwkOMDNGPIPsNb1wp5g3jX2dyZeEdiB6jvUDDjGyHrerUkawbo buCFNko4PUXXmPYAYrMyAxjVF40izHjkroo/Q6dxWlbDaYKjXyr4msSLAWJROJC5ebFmMBEZ6 ONM/9Lwn8PuO0DOIon9nFuggrZ7/bHPRuTAaVTVgkyVy1XPkAfJDty1mMdy8h+c3B/2mls98e SfOT/rgOHy7dd/LZ0INUC7jinOJ8p/UG2HkJ7UyXopMzMiZrHnPiqS1o3o7FlG7ONFDmoPaVv RbQP7pBbrvlhhI4tCRkmS48bhOUQbFcVxV4JZxHEph/FSbOYmZ3kwT9+jMn+zjQXqwvI46A+6 zZC8MOpGqcqLt3nogkwG5Zr+L2jFprFa8n9ZsqYwoItknK272Z13YGSk56kU9Eiaf01qegg1y h8afbeJDrnz6tFpP2F05fZRwG3fm6l1sN0b1XopLYhW4oI81QwE2lsnbBgTGeWuRABjcZmVsa UCPvXV7rW3ZRFOBUlWLu83xpa3VGJDKfjZM9DA== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1 -> (file-notify-handle-event (file-notify (100272320 added > ".#-emacsa05420") file-notify-callback)) > | 2 -> (file-notify-callback (100272320 added ".#-emacsa05420")) > | 2 <- file-notify-callback: nil > 1 <- file-notify-handle-event: nil > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1 -> (file-notify-handle-event (file-notify (100272320 modified > ".#-emacsa05420") file-notify-callback)) > | 2 -> (file-notify-callback (100272320 modified ".#-emacsa05420")) > | 2 <- file-notify-callback: nil > 1 <- file-notify-handle-event: nil > > I'm confused: why does it mention a lock file instead of some file in > temporary-file-directory? Is some variable missing a value? Well, the lock files are from the write-region call. I see something similar for inotify: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (create) ".#file-notify-test= 20231Yhx" 0) file-notify-callback)) | 2 -> (file-notify-callback (2 (create) ".#file-notify-test20231Yhx" 0)) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (create) "file-notify-test20= 231Yhx" 0) file-notify-callback)) | 2 -> (file-notify-callback (2 (create) "file-notify-test20231Yhx" 0)) | | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx")= created "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx")) | | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2=3D= "" ((#3=3D(should (equal (car file-notify--test-event) file-notify--test-de= sc)) :form (equal (1 . #1=3D"file-notify-test20231-Ml") #4=3D(1 . #1#)) :va= lue t :explanation nil) (#5=3D(should (string-equal (file-notify--event-fil= e-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-e= qual "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6=3D"= /tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))]= [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t = :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent202= 31MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed= #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :for= m (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231= -Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 = . #7=3D"file-notify-test20231Yhx") (2 . #7#)) :value t :explanation nil) (#= 5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-te= st20231Yhx" "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx"= ) :value t))]) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (modify) "file-notify-test20= 231Yhx" 0) file-notify-callback)) | 2 -> (file-notify-callback (2 (modify) "file-notify-test20231Yhx" 0)) | | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx")= changed "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx")) | | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2=3D= "" ((#3=3D(should (equal (car file-notify--test-event) file-notify--test-de= sc)) :form (equal (1 . #1=3D"file-notify-test20231-Ml") #4=3D(1 . #1#)) :va= lue t :explanation nil) (#5=3D(should (string-equal (file-notify--event-fil= e-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-e= qual "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6=3D"= /tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))]= [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t = :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent202= 31MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed= #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :for= m (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231= -Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 = . #7=3D"file-notify-test20231Yhx") #8=3D(2 . #7#)) :value t :explanation ni= l) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-noti= fy-test20231Yhx" #9=3D"/tmp/file-notify-test-parent20231LXr/file-notify-tes= t20231Yhx") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (= 2 . #7#) #8#) :value t :explanation nil) (#5# :form (string-equal "/tmp/fil= e-notify-test-parent20231LXr/file-notify-test20231Yhx" #9#) :value t))]) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (delete) ".#file-notify-test= 20231Yhx" 0) file-notify-callback)) | 2 -> (file-notify-callback (2 (delete) ".#file-notify-test20231Yhx" 0)) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (delete) "file-notify-test20= 231Yhx" 0) file-notify-callback)) | 2 -> (file-notify-callback (2 (delete) "file-notify-test20231Yhx" 0)) | | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx")= deleted "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx")) | | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2=3D= "" ((#3=3D(should (equal (car file-notify--test-event) file-notify--test-de= sc)) :form (equal (1 . #1=3D"file-notify-test20231-Ml") #4=3D(1 . #1#)) :va= lue t :explanation nil) (#5=3D(should (string-equal (file-notify--event-fil= e-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-e= qual "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6=3D"= /tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))]= [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t = :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent202= 31MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed= #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :for= m (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231= -Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 = . #7=3D"file-notify-test20231Yhx") #8=3D(2 . #7#)) :value t :explanation ni= l) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-noti= fy-test20231Yhx" #9=3D"/tmp/file-notify-test-parent20231LXr/file-notify-tes= t20231Yhx") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (= 2 . #7#) #8#) :value t :explanation nil) (#5# :form (string-equal "/tmp/fil= e-notify-test-parent20231LXr/file-notify-test20231Yhx" #9#) :value t))] [cl= -struct-ert-test-passed #2# ((#3# :form (equal (2 . #7#) #8#) :value t :exp= lanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LX= r/file-notify-test20231Yhx" #9#) :value t))]) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 -> (file-notify-handle-event (file-notify (2 (ignored) nil 0) file-notify= -callback)) | 2 -> (file-notify-callback (2 (ignored) nil 0)) | 2 <- file-notify-callback: nil 1 <- file-notify-handle-event: nil `file-notify--test-event-handler' hasn't been called for the lock files, because it was enabled for the test file only (that's the intention of this test case). It isn't clear to me why `file-notify--test-event-handler' hasn't been called for your test file. That must be something in w32notify.c. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 12:52:01 +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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144232148010315 (code B ref 21432); Tue, 15 Sep 2015 12:52:01 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 12:51:20 +0000 Received: from localhost ([127.0.0.1]:32822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbphf-0002gJ-CN for submit@debbugs.gnu.org; Tue, 15 Sep 2015 08:51:19 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:53475) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbphc-0002g8-QC for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 08:51:17 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NUP00J00Y6VNR00@a-mtaout21.012.net.il> for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 15:51:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUP00J5JYDENP10@a-mtaout21.012.net.il>; Tue, 15 Sep 2015 15:51:15 +0300 (IDT) Date: Tue, 15 Sep 2015 15:51:16 +0300 From: Eli Zaretskii In-reply-to: <87zj0nx5i7.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83a8sn977f.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: tsdh@gnu.org, 21432@debbugs.gnu.org > Date: Tue, 15 Sep 2015 13:54:08 +0200 > > It isn't clear to me why `file-notify--test-event-handler' hasn't > been called for your test file. That must be something in > w32notify.c. What kind of "something"? Notifications do work, and the rest of the tests pass. So it must be something with this particular test. I think the problem is due to the fact that the directory is deleted inside the file-notify--test-with-events form: doing that invalidates the watch, so the events are not reported. If I remove this line from the macro body: (delete-directory temporary-file-directory t) then the notifications are received as expected: Test file-notify-test04-file-validity condition: (ert-test-failed ((should (equal '... (mapcar ... events))) :form (equal (created changed deleted) (created changed)) :value nil :explanation (proper-lists-of-different-length 3 2 (created changed deleted) (created changed) first-mismatch-at 2))) (There's no "deleted" because it's caused by delete-directory call which I removed.) So I modified the test to have the directory deletion outside of the macro, and the test now passes. I also increased the timeout of read-event, because 0.1 was borderline: it sometimes worked and sometimes didn't. Please see if the modified tests work with inotify (they did for me on GNU/Linux). From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 12:57: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144232178611059 (code B ref 21432); Tue, 15 Sep 2015 12:57:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 12:56:26 +0000 Received: from localhost ([127.0.0.1]:32835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbpmb-0002sH-Jc for submit@debbugs.gnu.org; Tue, 15 Sep 2015 08:56:25 -0400 Received: from mout.gmx.net ([212.227.17.21]:57362) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbpmX-0002ry-Jt for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 08:56:22 -0400 Received: from detlef.gmx.de ([93.209.81.17]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LyB6P-1YZQoL1vCn-015ZTc; Tue, 15 Sep 2015 14:56:20 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> Date: Tue, 15 Sep 2015 14:56:19 +0200 In-Reply-To: <83a8sn977f.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 15:51:16 +0300") Message-ID: <87twqvx2mk.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:0rS/tWFwnNTJ31EB1p0KpIdy/p+y8C+6JWzo7aCcbjFm7bbMUuM qgJIJwKICOZ7UPdUXUdoMkitwN9TRI5nBGzSHHPmcNUnQYoRiKWJZ4NlZUTb8hKHk0wYzaU RLk5yICn3k77HheKX5OarEp5w5gFG3pN6lnpAv+/xlUf/L8iobj7pLbHINo65OYoXaDnerU 1elPA2zbtH2hLg4bLIrgg== X-UI-Out-Filterresults: notjunk:1;V01:K0:mcWQh9udYto=:3wgbLYbfzlT2XerQxPz0Ny uDXUfqLxrHn9qSo+EQKsiGAXKkPj0lTaLeEOJVeIqx96ezIP47EOp+HveFEQDjrhhvbW1BB6z J/++bv8d9eApiH8ITESdogvA1Jv/7LowU12yxBW61nyKa9mf7Wx+hhWNM375yK45AN/D36+Lm +BGdq54DVzJIY490hJvz6kvI4y2EMTCTqZWbyXVvxV9Mzk4tV7Dl+cHSXZ2ki/cyYOoH9masW 9OGZvaol8Vrftexbm8VsAgcCN/oy9hJ/rgvWXqV58ekyt7DhJt099rZ/0sdWbKb8PObf9rSFm I/514J9IVYG1S/RQpOJg8RHbNk1HOkpbeBxxuuQq2FiW1tMgnp2Ot9xfpsXNU25cUEq0ECjzh bZoVWQOvRHOhd++3oZ8598yYMZYSOeZmXWHSHmviwx+LdlnSFZf0BG9S6V5dKYibNw7NoKqCP Sg1DwnpdIZ7rEklKOE1vEi9Kqu2wi/IY9dC/zReMm7zy+HLUY0j9IdUYBMHlOFWF6Cnv1CxU7 AFKjKNPGB7OtW1vXAw0454zust1Q3dp4tZ7VBk7k3/AUG7YJ59KRyk8kyUT8CUCgTtOh/8vCr CyhUX6yyFfQHgvo5pQpwhPXfxfXxmTd1AFqAQTELNaHqIwch+zuAFoBs6kddnlAqQPPGKTiEC 8o1Pmvy6LgRytyBWXJjRfwR7WmqFRTA7Bte+MPvbxdgsGc/bgBQZ0yYupruHLSZVDU2vmKoxW 5L4MRz8Fno0wUnyEnsuC7XyWLQjwkADZgU3GaQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > So I modified the test to have the directory deletion outside of the > macro, and the test now passes. I also increased the timeout of > read-event, because 0.1 was borderline: it sometimes worked and > sometimes didn't. > > Please see if the modified tests work with inotify (they did for me on > GNU/Linux). Works here. And also `file-notify-test04-file-validity-remote', which did fail before. Thanks. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 13:03:01 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144232213411914 (code B ref 21432); Tue, 15 Sep 2015 13:03:01 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 13:02:14 +0000 Received: from localhost ([127.0.0.1]:32842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbpsA-00035y-EJ for submit@debbugs.gnu.org; Tue, 15 Sep 2015 09:02:14 -0400 Received: from mout.gmx.net ([212.227.17.22]:63791) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbps4-00035i-H1 for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 09:02:08 -0400 Received: from detlef.gmx.de ([93.209.81.17]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ll0tl-1Z499D2STV-00aljq; Tue, 15 Sep 2015 15:02:02 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <83mvwpa1xb.fsf@gnu.org> Date: Tue, 15 Sep 2015 15:02:01 +0200 In-Reply-To: <83mvwpa1xb.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 10:35:28 +0300") Message-ID: <87pp1jx2d2.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:CPfL3L+pKm5mOBEWjgIoyrXs/oQE/hZ5bXcLiZJ4ZwTI7MF7VSG AIJbqvimIVk2FLBwgsFaeTe6vvrzhy6kigLlsU/zZ4AoVGnx9dYIp741v+ppxu1xOp6d68D 2PdGdQhlWVe6V7hZq2GAaFEgntauNOamlsGte98ouw23NWLZqikVYU28SbYRogDob6YkoR3 nPlq4IzxEkQfOn719YbZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:RWe/U5ge89E=:iFWX5hw/9QipICRN2zzyMJ x4vqIOo0bRGSwPNWLkIRwtiQUrnEr8erYvMDbpC3qiBzeTw2SSIV7tDVb7UuQUkpcUILv0b5f JZCvEq8VKOLSDhj+gF9ZFbleTTuGSPodqSd5eX0B09fLOwI6ZanWtuKjS8g27Cl08+VKmzvwp pL9cbHvSnoC3OuYCTx1GHl1EGIwEFZZgi3byKYuEb4Va0YAvdzaOWK7kiyvXhQireYUzqDPtf hX6ruIHmZ/Mjf98ZcGw+4l11RdvnurB9rd4Qtk8SNYEDQDpECP4jjIaCUOlWKBqmAib68EvHy EbsUO0fXy+654yz2jraz6UYRVzJSLAWuUkOeER/gesqDM8k7iX0UTQWdhUpFhQFqT9VRT0cuL xuzhQQ/dBL8FKz6GCPvSzWtyjsLuEetfE04ZVBS1XnsvwLDw5zRJ7qjaqTgmLO+OaIyabyUFL eACEQG5Mh43ua+uYl9niuFkgeItsa6aNNpBWqQGa9PvB4GWD5XhNbrPie5sEwXVumLiaU5wZf nD16SUaXXKNFTSOBFqkuG1KiWlqRf44rPI9fsii4SqeXMqyKUEjHVbA0kkPt0XGeEbfD5nAxz vqko0hFOYmCmDfUJ9HwnuNnBOTvF0+UzQEJV39Wwzp59iMq7/FqAvt2GLez/KgKjeWosYikI+ Pkv0yTuni8GHNQkso59iosY89/qx56N4l/5RdBhg73Qxn0cJuCXURVOPwEjra3NyCYNJTVit4 MHiqdxpf+8sCTtdDBfZqSMJ2c8IwUqK5NxbxrQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > I find the way inotify.c and gfilenotify.c report errors suboptimal: > they don't report the errno value and the related data, so the error > messages tell less than they could. I went the way similar to > report_file_error instead. Maybe the other back-ends should follow > suit. I've changed it in inotify.c. I've simply cloned your report_w32notify_error, called it report_inotify_error, and adapted all error reporting places. However, wouldn't it be better to have a common function the three backends will use? A report_filenotify_error function in fileio.c? Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 13:57: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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144232539325846 (code B ref 21432); Tue, 15 Sep 2015 13:57:02 +0000 Received: (at 21432) by debbugs.gnu.org; 15 Sep 2015 13:56:33 +0000 Received: from localhost ([127.0.0.1]:33338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbqim-0006io-Js for submit@debbugs.gnu.org; Tue, 15 Sep 2015 09:56:33 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61346) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbqih-0006ic-LL for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 09:56:28 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NUQ0080017WG500@a-mtaout22.012.net.il> for 21432@debbugs.gnu.org; Tue, 15 Sep 2015 16:56:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUQ008NF1E1CC30@a-mtaout22.012.net.il>; Tue, 15 Sep 2015 16:56:26 +0300 (IDT) Date: Tue, 15 Sep 2015 16:56:27 +0300 From: Eli Zaretskii In-reply-to: <87pp1jx2d2.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <837fnr946s.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <83mvwpa1xb.fsf@gnu.org> <87pp1jx2d2.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: 21432@debbugs.gnu.org, tsdh@gnu.org > Date: Tue, 15 Sep 2015 15:02:01 +0200 > > However, wouldn't it be better to have a common function the three > backends will use? A report_filenotify_error function in fileio.c? Yes, of course. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 13:55: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144241169320435 (code B ref 21432); Wed, 16 Sep 2015 13:55:02 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 13:54:53 +0000 Received: from localhost ([127.0.0.1]:34306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcDAj-0005JX-DB for submit@debbugs.gnu.org; Wed, 16 Sep 2015 09:54:53 -0400 Received: from mout.gmx.net ([212.227.17.22]:65362) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcDAh-0005JN-7y for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 09:54:51 -0400 Received: from detlef.gmx.de ([93.209.70.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mg3h3-1ZGwto3nRV-00NP1W; Wed, 16 Sep 2015 15:54:50 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <83mvwpa1xb.fsf@gnu.org> <87pp1jx2d2.fsf@gmx.de> <837fnr946s.fsf@gnu.org> Date: Wed, 16 Sep 2015 15:54:48 +0200 In-Reply-To: <837fnr946s.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 16:56:27 +0300") Message-ID: <87k2rq5v13.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:48R5K49NvqtNRk2sODVKtOfFLqO3e4fyqZMNrm4h4ptuX1zYzRW r94MjAn1XgQzzhKn3AdXhNc8KTpoQRhsD2esrs7uTGFlzONxPB2Ca/BxIiPybpI1H9Y1Ya/ zoUqJnq9g/U3xV5VNaqEMbUCQjDdwr/OHS4HRS+xck1OwG15WtNdg1voNWzyi7QsRVCrBbf KihkSNkADRS1SlwSLNsSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:4qxZ0OJyFR8=:vKlivvgCsXqcP52A5MhT4W DeASNE4hF0wCsHw5Li+LdvLMY7wXU84FEd/dYKr7awNv5W/vicqFx4ppIwknvIs0EOXW5uyKe fixJxDSKSh+airMd2YMHVxFasGmhxoFppVztL7iirODYqZYCwFuVNL5LCKAmQEur917uEPLSs cMudWxGb14jC828LZHrzfiulAIYdGQ60IiCUWecAcwz+CjJ433P3Iw/bM2C4eEhtziuDb9zG6 i4FBdvEn7wH5q1H/HerCLraCOAWQFH3H1MQlfaYaef6P9EBdtAoaEN/KXmtjza9hp3DV9xYmh bE4FmRTHqwzi//UXIXbU6hb4fX/Vgvcg8N3ZLtQosLum7M8q5y2gTDDC0A5g0HdwpYCFYsB4y /u1DN16HwsFQ9LCO2hHbzhNX2YQgLOnWlQUTQyCsELgD/OWzKIEE0xAF5sPclF8mf1UvTxPzk O9Z75yQ11G8a069nFFGzEchBA/221sjngenysZZAWjqu7Z2qt9KgYhksvtnmdzYH/PGcM0jPV 3+/WGtNKGGFbPL8UfgVg+0gYeAB/NwCFHVJ1tsbfehq0jRJlgVgddCxf4CbOgcsoUpJ25zYEm Nh3mAGMaNbq9xMog53W21FMuSDlqpYY1uTFF43u7G+lhKvJJMgKd/8BxJJfTBN2g766JCchpd Rc3ayfyXnIPq6AjQu3C2qaxIpgJZe2VqYzCo6Z1+s2nTXgfotGBM7iEAK3PKI3ao6cVDpaYyA qjqUdddfJYCLrGx4s5phDe81RpNwDmImvpl1oQ== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> However, wouldn't it be better to have a common function the three >> backends will use? A report_filenotify_error function in fileio.c? > > Yes, of course. Done. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 14:46: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144241476126464 (code B ref 21432); Wed, 16 Sep 2015 14:46:02 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 14:46:01 +0000 Received: from localhost ([127.0.0.1]:34968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcDyC-0006sl-MY for submit@debbugs.gnu.org; Wed, 16 Sep 2015 10:46:00 -0400 Received: from mout.gmx.net ([212.227.15.15]:50101) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcDyA-0006sb-Uq for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 10:45:59 -0400 Received: from detlef.gmx.de ([93.209.70.110]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M08ia-1YkGuA0NpM-00uIjV; Wed, 16 Sep 2015 16:45:58 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> Date: Wed, 16 Sep 2015 16:45:56 +0200 In-Reply-To: <83a8sn977f.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 15:51:16 +0300") Message-ID: <87d1xi5snv.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:vW7HkhIOEmfEaoEyGb8RquSLdTnpnfLnIGl3BqBY6tMZqT0OgxH oGzPfE0GcvMvJXejBIkR5iF3XKEoma9m3K2JlGA4gCAk+Xe/YkgdwmlvbbftX8McDVksw4I md8hDsUtV+3FIa5H1H2BE4OwjdCTBQV5KdN5FLUPKrWV3nR8DJ40pyOZ/Y4VBqiWBXp1tiI NrP6BooUSpcD+TdSvEY0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:0MnbwWtiRWA=:8b4BhVsCDb8dtoC6+GABl4 TJJE1zVjqsFDk1pbhOS7Y5hCmvf0yQAX83AREneTlnYtmHWt9Shu8OBHxQ+VwulCj9cBTNKg/ Sbd1q+PKM0PKnKxyqBR9zQksVrQF7hcvKmY/72YBhxtt5Cb3GNkemba0e2OBRIEIlQD8RseUb GVCwI59zRUfbSlZIdmLk2RiHuXan+bvYrAux4EX9o6I3v0RVcyG0wtgacygpEiJRfWYT3mjs8 VOglZdsMDN7iXudS8fyopGRF+2JOB+hWulEGk/Y5BAXt15nJvBLTJg6c+StIc7gwlGiohndpN Hz1sHMOOBllBt+tyB7JVQd0ooLGpF9JJV/GIAHdBDdxw+K7F+ENpffzkUq9ptNk2OHee4F9tl ZCfShg/d0gUTqSJR86Gk9TrBxjP2CKeneX8HqLtWXwrR9cJ9MvpouJHySrHXDevRNeQbfbWnw Z8VIDUyutx0LH3zq33u2iVWCv61IZP7eBxaO6MoMCx0WQG5ATpUDIoXHVwqcfsVCeNZLf1yHV dbJIcRjhCXe2gQj1dGhoreCeKESCGpaEiB82hvCCLw1s/1Ryc7m8Ui8S8MKe89oKTm1V3TSlC azT2inmGZW0bCI9VBdlFdQuhqyycqBMbY1ZnBDlp6nbENyeuepzsxy7dQphcaUQobOp+KfEMB dszLysYtP+6bj/v104zpzMENSqS1OJXbrG9Osx4e5D9X5W3pSN6hEtkmG9FD/HUJcYUan98qW HY41DvrfKKMuSqNmyJJH3utBaNZB0jKx5TZU4g== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > I think the problem is due to the fact that the directory is deleted > inside the file-notify--test-with-events form: doing that invalidates > the watch, so the events are not reported. If I remove this line from > the macro body: > > So I modified the test to have the directory deletion outside of the > macro, and the test now passes. I also increased the timeout of > read-event, because 0.1 was borderline: it sometimes worked and > sometimes didn't. I've checked further. In `file-notify-test04-file-validity', you have also removed the final check for `file-notify-valid-p': ;; After deleting the parent, the descriptor must not be valid ;; anymore. - (should-not (file-notify-valid-p file-notify--test-desc))) + (delete-directory temporary-file-directory t) + (read-event nil nil 0.5)) Was this by intention? The whole test case is about this check. And maybe this is also the reason that it passes now the remote test case, surprisingly. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 17:09:01 +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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144242333211640 (code B ref 21432); Wed, 16 Sep 2015 17:09:01 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 17:08:52 +0000 Received: from localhost ([127.0.0.1]:35023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGCR-00031g-Ho for submit@debbugs.gnu.org; Wed, 16 Sep 2015 13:08:51 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:48544) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGCN-00031S-1L for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 13:08:48 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NUS00K004U3T500@a-mtaout22.012.net.il> for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 20:08:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUS00KSC4YKRH10@a-mtaout22.012.net.il>; Wed, 16 Sep 2015 20:08:44 +0300 (IDT) Date: Wed, 16 Sep 2015 20:08:44 +0300 From: Eli Zaretskii In-reply-to: <87d1xi5snv.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83h9mu70mb.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> <87d1xi5snv.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: tsdh@gnu.org, 21432@debbugs.gnu.org > Date: Wed, 16 Sep 2015 16:45:56 +0200 > > I've checked further. In `file-notify-test04-file-validity', you have > also removed the final check for `file-notify-valid-p': > > ;; After deleting the parent, the descriptor must not be valid > ;; anymore. > - (should-not (file-notify-valid-p file-notify--test-desc))) > + (delete-directory temporary-file-directory t) > + (read-event nil nil 0.5)) Oops! > Was this by intention? No. > The whole test case is about this check. And maybe this is also the > reason that it passes now the remote test case, surprisingly. Does it work for you if you add the test after read-event? It fails here, i.e. the watch is still valid. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 17:27:01 +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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144242441713898 (code B ref 21432); Wed, 16 Sep 2015 17:27:01 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 17:26:57 +0000 Received: from localhost ([127.0.0.1]:35040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGTw-0003c3-Qa for submit@debbugs.gnu.org; Wed, 16 Sep 2015 13:26:57 -0400 Received: from mout.gmx.net ([212.227.17.21]:62032) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGTs-0003bq-Pw for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 13:26:53 -0400 Received: from detlef.gmx.de ([93.209.70.110]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MXDo1-1Z8L8Q0fmn-00WIEG; Wed, 16 Sep 2015 19:26:51 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> <87d1xi5snv.fsf@gmx.de> <83h9mu70mb.fsf@gnu.org> Date: Wed, 16 Sep 2015 19:26:50 +0200 In-Reply-To: <83h9mu70mb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Sep 2015 20:08:44 +0300") Message-ID: <878u865l7p.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:vryyWWlLBI0HhNE5j841ZvG8Z0ia0diNR9sxBYGz87al+TfOznJ I/gPaXTDD5WfcopjJQw9NhiidFKghAwZvVaVSEVxybTg5drUHMqa993Y+JXXxi8qDj3HopT o9A3L+oKWiLC9eGMbsSsvYlu8T7CbtpzLqKwFgqZHp95EGVh+ZdrBpAO6JMartEGF1JAd+x kmpHrxwp+VdBTPJo6yMTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FMi9UxMQfHM=:7p6/uPHQsCvg7iLjE028XF MnEpPXL4LDX5Sdmrrnt3p71649fyKotp5d61vohm1o/hqY+ouLStXoEt2e79Wz37oHFmeyMVC fVz2n1vQoRq+kClM2xZ5hwuxM9vXAz42R0JzQRjNL5awlwGjZPcURunfZrji4Gy33OmDVWQwc ElW4zJyh8wWu1SPbKO3F0ookFB30cHYZD1jDGP0NACJTbIfK3sScNL0E0ChMiDp2GEylhmwu5 G959JXXJQst/PDTGdp2qUR1c4117J2Ej1M2CoFYBmJw1TXlQ7JYJN73YOgxrRi10oxUh3OWjz WBkUMSdqdqBOEIAMXTZCxXTZSEyAgBaJx+Dk8KU1292yGM2rmnOSOza05SHKX542EU91aYKm9 rbbBJWpU80+mrHhHYVdOzeFf8pz72hG/PuxYg8cauzp3ov1dE84thtKZlTNOvyQmLzthjNUWg 8yv8PiKGKo+JSYihd1XScY7Xq2WiodAJ6MinTL6rnhB8WUdFJZHQB++NcLVBPoLJFq+MB/VD3 IDTO87MtLpoyBvmLzFgI7alsv43wG90PsF+MPzcpccbRp8wxeehL5dGrEJ4gMYuKOYs7VsOGp g3yRlgfGZc22NI6NT15l3QMvqc02z385kzpBXTuVIAiYQ4JrBCBxsoCXckGoLIe7BE0MDwP2b /mYLCfCtah32miec9LBjCSFXnJ/6POn0X2VuHdzCWHalwMl/JHhjHxciuyrTkQdG5nqz3c5sW 0twA5KHpgoC9V7dMMM0PLgMmHJvuFjmmQgqHNw== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> The whole test case is about this check. And maybe this is also the >> reason that it passes now the remote test case, surprisingly. > > Does it work for you if you add the test after read-event? It fails > here, i.e. the watch is still valid. Yes, it works for inotify. And `file-notify-test04-file-validity-remote' fails as expected, 'cos I haven't fixed it yet in Tramp. For inotify it is obvious that it shall work. All inotify watches are based on inodes. If a file is watched by inotify, and the parent directory of the file is deleted, the inode of the file itself disappears. I don't know how it works with w32notify internally. And I don't know yet how it will behave with gfilenotify, all checks for that backend I have moved to later. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 17:58: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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144242623517631 (code B ref 21432); Wed, 16 Sep 2015 17:58:02 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 17:57:15 +0000 Received: from localhost ([127.0.0.1]:35055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGxG-0004aJ-L0 for submit@debbugs.gnu.org; Wed, 16 Sep 2015 13:57:14 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:56501) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcGxD-0004a6-Ek for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 13:57:12 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NUS005006WFSM00@a-mtaout20.012.net.il> for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 20:55:19 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUS005M1747KJ70@a-mtaout20.012.net.il>; Wed, 16 Sep 2015 20:55:19 +0300 (IDT) Date: Wed, 16 Sep 2015 20:55:20 +0300 From: Eli Zaretskii In-reply-to: <878u865l7p.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83eghy6ygn.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <83oahc7vxr.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> <87d1xi5snv.fsf@gmx.de> <83h9mu70mb.fsf@gnu.org> <878u865l7p.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Cc: tsdh@gnu.org, 21432@debbugs.gnu.org > Date: Wed, 16 Sep 2015 19:26:50 +0200 > > Eli Zaretskii writes: > > >> The whole test case is about this check. And maybe this is also the > >> reason that it passes now the remote test case, surprisingly. > > > > Does it work for you if you add the test after read-event? It fails > > here, i.e. the watch is still valid. > > Yes, it works for inotify. And `file-notify-test04-file-validity-remote' > fails as expected, 'cos I haven't fixed it yet in Tramp. > > For inotify it is obvious that it shall work. All inotify watches are > based on inodes. If a file is watched by inotify, and the parent > directory of the file is deleted, the inode of the file itself disappears. > > I don't know how it works with w32notify internally. And I don't know > yet how it will behave with gfilenotify, all checks for that backend I > have moved to later. It works for w32notify if I run the test in an interactive session. It only fails in batch mode. Since the batch-mode operation of w32notify is fragile (there's no input threads to send the message to), and we have already wasted too much time on this tiny feature, feel free to skip that test when in batch mode and w32notify back-end is used. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Sep 2015 18:29: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: To: Eli Zaretskii Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144242810121394 (code B ref 21432); Wed, 16 Sep 2015 18:29:02 +0000 Received: (at 21432) by debbugs.gnu.org; 16 Sep 2015 18:28:21 +0000 Received: from localhost ([127.0.0.1]:35063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcHRM-0005Yy-Eh for submit@debbugs.gnu.org; Wed, 16 Sep 2015 14:28:20 -0400 Received: from mout.gmx.net ([212.227.15.15]:51461) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcHRK-0005Yq-Pu for 21432@debbugs.gnu.org; Wed, 16 Sep 2015 14:28:19 -0400 Received: from detlef.gmx.de ([93.209.70.110]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M7pI0-1YgztQ3BiK-00vN2u; Wed, 16 Sep 2015 20:28:16 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> <87lhcgvr1t.fsf@gmx.de> <87r3m4hrfq.fsf@gmx.de> <83fv2jbrkm.fsf@gnu.org> <87zj0rh5lb.fsf@gmx.de> <87h9myt96l.fsf@gmx.de> <87zj0pild7.fsf@gnu.org> <83oah5a35p.fsf@gnu.org> <87vbbdih3w.fsf@gnu.org> <87r3m1igdf.fsf@gnu.org> <837fnt9lup.fsf@gnu.org> <87mvwoycl3.fsf@gmx.de> <83mvwo873t.fsf@gnu.org> <87bnd4xgc5.fsf@gmx.de> <83lhc8852n.fsf@gnu.org> <87zj0nx5i7.fsf@gmx.de> <83a8sn977f.fsf@gnu.org> <87d1xi5snv.fsf@gmx.de> <83h9mu70mb.fsf@gnu.org> <878u865l7p.fsf@gmx.de> <83eghy6ygn.fsf@gnu.org> Date: Wed, 16 Sep 2015 20:28:15 +0200 In-Reply-To: <83eghy6ygn.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Sep 2015 20:55:20 +0300") Message-ID: <874miu5idc.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:7bN24S5NT87nE1qkpn0jm2hssKJel9t7Vaci0Ydm79suViX/viC 3nTnGeO5L6+3sWol/FhJaj7posc49eciaAIyyu3zvDVH0bwZixwKKM9tmjc17rrKAKMZ/Ve Ma0RtSURfZAXDiH66dXxXSYEsClhapDLQixiZ6jkmFYyll05X7M4wWlpxpwm3vVHDT2Djsa lPTOC4P+FpLv8diD9ifsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:52bEdireY/I=:rnsdt6UGeE2HmvhtBxBdVw UqgNPrZy3cRwgM77f1l1OAG5YdzmENuacfdQgUf6IrI/N6ArM777KBSNlYlKk29X7O1pndaae AeZEpxmhKssb3AFc4OW5261JQya4TZ3uPU+pMMH3Hx5K7cu/k8KBzwAjKhJStH0TP1oo8ifsv 4QRII7lK+dKRogCY8oJsiMVjyNA3Sk7N7nSUP3xuMFyqSFfb7i/pBc1HtYdtiNs+d9fUxMqvV ELrFOr834N2woP64RAPdhmJKbEvYg+pu3AUNR9B9uMPDr9WeJ4wChIry6ZT8j06MQmVLuNsSa riT3x2L1GYaG1qXNRRrgMTIDh413VSchyTYCB9EhZ4fvXeHiJhhAH28MSVZAcgJEDRx26vbmf deYW6eDfJM9iezN97UqrhrzGMtxl9Alg+DsbIG7kAJglpqyyDlH3LJAoBnKzyE4vNkVZVma8g O5T9sSFOaTltHvYsxLdAWyRptORYBOI0K0zCckMhcoW5v3dmLdRdP/kq6ONIrVBz7rMGNL1lK rmpgpuyer9LgMU4w9nLofAhTcqX0QtZWA8oZEOkf9XMDuzJMfbdwZtNcWME7ZGKfq5EzR/NDH EfJsqMmcwftgJdQxqA8SnXH6k7Y4jFPTa6dnPW+FWsa960oxLeNomAgbQI9HqAy+6k+XXCwXO 0tCxgharpgJiJJr/K/pgQpmRPfBMDiWfSopwwXUn9X1oZytu73nwpc8rnFtkJ2JYp7sxlHvAf zKZOzKma8o15/LS9lcK4dpmVF1YJh5wzWs0NxA== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > It works for w32notify if I run the test in an interactive session. > It only fails in batch mode. Since the batch-mode operation of > w32notify is fragile (there's no input threads to send the message > to), and we have already wasted too much time on this tiny feature, > feel free to skip that test when in batch mode and w32notify back-end > is used. Done. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Sep 2015 17:25: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: To: Tassilo Horn Cc: 21432@debbugs.gnu.org Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.144276984327960 (code B ref 21432); Sun, 20 Sep 2015 17:25:02 +0000 Received: (at 21432) by debbugs.gnu.org; 20 Sep 2015 17:24:03 +0000 Received: from localhost ([127.0.0.1]:38996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdiLK-0007Gs-QQ for submit@debbugs.gnu.org; Sun, 20 Sep 2015 13:24:03 -0400 Received: from mout.gmx.net ([212.227.15.18]:60208) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdiLI-0007GR-4q for 21432@debbugs.gnu.org; Sun, 20 Sep 2015 13:24:00 -0400 Received: from detlef.gmx.de ([87.146.53.101]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LdYdG-1YuzaZ0kza-00ij0x; Sun, 20 Sep 2015 19:23:57 +0200 From: Michael Albinus References: <87k2s15sfd.fsf@gnu.org> Date: Sun, 20 Sep 2015 19:23:56 +0200 In-Reply-To: <87k2s15sfd.fsf@gnu.org> (Tassilo Horn's message of "Tue, 08 Sep 2015 08:36:06 +0200") Message-ID: <87d1xdngwj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:hEYpe/KfuHp4VU5Y9miraQedm0MLCHoyIN7BJodGj+KdUMKwFtm RHKPWKUyCvKukyZNcP2S35MM0iEAhNoxAJ6V3YUQnJ+q1kKT8zGqDrdvrfXW5volbw0BwZb Bm8NjATjq1fGg31kUsjdPZubf2OBPNRKyYWl64Rl/E7cDBTosSIGAUJTSp3LspfKkC6b+vH qyCExmPYWMOwiO/iJNP3g== X-UI-Out-Filterresults: notjunk:1;V01:K0:n4jJlfOwYRQ=:rJV00lpu81LZFrXAAJO2Iy /Yb8Llx41F+l4Z7qyJxHjLg9dmQBTjP0eVjEb6hznEu+sKk74MbQfzyyO5b6LV2EJp+wSMUZ8 Xwi19J1a8c3kxpA/L8zEs++/bsOKNQ0OpDX/NCYs3w7zsT3BvNG8LNEbfhWnVqFNEqX3TdqYW ZiknC74Ma3S8smvg3jepba4IC7yBJyKwbCjeEo3jwmTz4/OVOrYTrDFmFZAyXzdUa1KyHVfK1 Tibz4DW6rA6ndxFr51bM17CD/B2yjcd+qhZjJnjq3u1g/9zL7P0SUEEifVI5wSG5XS+n6DSTk Y54x8IzsmWbudi2hbwP6v+DBt9uNeYGjSX0d+Qc5g2NPwUDqgTWbykLAZmNrMttmEUlyavgHs XNSKwhWo+scddioyE+UTHUPXLrSBK0fO4NskTXVzmEwnvsxCk8NEmeobB0p1A+dHvCJqGjaaN Tfs9seIh6NJvKV9X3n4bOBC1gPeDZjVEOOuR3bR0CJoUhvt99SAevrhDfgCC+tXH6DbP4Qm6q CIQpV0ThsESNnNul5Z6ahFBWHqd69QIOro+D3stxhBNvQ5g4t2I6OTgMWZP7dX7hYZuhIJGHE cc2ULOK6Wk9+feYTYb1gpQ0eKnqq7YgodpjnkjcGyGheRV97wgHLejs4hR8eut8vAsjxB7X3d 6lVAuzVamupyyKHG5vpBeeLDSbURffCG+ampHFKJRYTeIX/ioXcS3wqp98dfdTsQS7dPYjFj3 RRMzFULGDr/Q1cshzMoUlSedNxSH9BtlnqWb/A== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Tassilo Horn writes: > Right now, (at least) the inotify version of `file-notify-rm-watch' > signals an error in case the given descriptor denotes a directory which > has been deleted in the meantime. If it denotes a file which has been > deleted, no error is signaled. I believe, everything what has been discussed in the course of this bug has been fixed now. I've committed a final patch for the Tramp case, and I have extended the test cases slightly with this patch. Inotify and Tramp tests pass all test cases. If there's no problem left for w32notify, I believe we can close this bug. There is still something to do for the gfilenotify case, but this I could do outside this report. Best regards, Michael. From unknown Sun Jun 22 07:57:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Sep 2015 19:20:01 +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: To: Michael Albinus Cc: 21432@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 21432-submit@debbugs.gnu.org id=B21432.14427767566152 (code B ref 21432); Sun, 20 Sep 2015 19:20:01 +0000 Received: (at 21432) by debbugs.gnu.org; 20 Sep 2015 19:19:16 +0000 Received: from localhost ([127.0.0.1]:39139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdk8q-0001b8-7K for submit@debbugs.gnu.org; Sun, 20 Sep 2015 15:19:16 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:33020) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdk8n-0001az-HJ for 21432@debbugs.gnu.org; Sun, 20 Sep 2015 15:19:14 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NUZ00M00PAQ5600@mtaout24.012.net.il> for 21432@debbugs.gnu.org; Sun, 20 Sep 2015 22:11:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUZ00H6APBQ4J40@mtaout24.012.net.il>; Sun, 20 Sep 2015 22:11:50 +0300 (IDT) Date: Sun, 20 Sep 2015 22:19:20 +0300 From: Eli Zaretskii In-reply-to: <87d1xdngwj.fsf@gmx.de> X-012-Sender: halo1@inter.net.il Message-id: <83zj0goq4n.fsf@gnu.org> References: <87k2s15sfd.fsf@gnu.org> <87d1xdngwj.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Albinus > Date: Sun, 20 Sep 2015 19:23:56 +0200 > Cc: 21432@debbugs.gnu.org > > If there's no problem left for w32notify, I believe we can close this bug. I don't believe there are any w32notify problems left we know about. From unknown Sun Jun 22 07:57:48 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Tassilo Horn Subject: bug#21432: closed (Re: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted) Message-ID: References: <8737y7oppx.fsf@gmx.de> <87k2s15sfd.fsf@gnu.org> X-Gnu-PR-Message: they-closed 21432 X-Gnu-PR-Package: emacs Reply-To: 21432@debbugs.gnu.org Date: Mon, 21 Sep 2015 13:41:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1442842864-12883-1" This is a multi-part message in MIME format... ------------=_1442842864-12883-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is de= leted which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 21432@debbugs.gnu.org. --=20 21432: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D21432 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1442842864-12883-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 21432-done) by debbugs.gnu.org; 21 Sep 2015 13:40:31 +0000 Received: from localhost ([127.0.0.1]:39694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1KZ-0003L4-62 for submit@debbugs.gnu.org; Mon, 21 Sep 2015 09:40:31 -0400 Received: from mout.gmx.net ([212.227.15.18]:51753) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1KW-0003Kw-JU for 21432-done@debbugs.gnu.org; Mon, 21 Sep 2015 09:40:29 -0400 Received: from detlef.gmx.de ([93.209.70.168]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRoyH-1a6zNi2hmj-00SzKx; Mon, 21 Sep 2015 15:40:27 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted References: <87k2s15sfd.fsf@gnu.org> <87d1xdngwj.fsf@gmx.de> <83zj0goq4n.fsf@gnu.org> Date: Mon, 21 Sep 2015 15:40:26 +0200 In-Reply-To: <83zj0goq4n.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Sep 2015 22:19:20 +0300") Message-ID: <8737y7oppx.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:C+aZH2HJXjuaURofPokHxOYlKElslSFEpJRknRR9RLQcqWJ+rIP xiNucXTLM69Fk2VpwAltW3fZW6u/Umw9riVoifG1DeHU3mXesAHYwn8wsYjAT4R0ufGvUXW IiAnqNRcegthF35PVYvBZWkHcVFjQVfiKxtWEVMpgUl3P47KCrkQnRB04jTVsJzbD2gg7p7 SR5uOcT2q9uN1d8DxYhQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:59Tyx6PCUVk=:pao2Fov/CEAzahScNWT0j1 HhcQxLmm6KmyDUfQRFrSBEcImv4rWPYzh+ymxGXRm94kMI44EG4aTTuhcutz1Mbvb+L2gSni/ ffd1CUAu1w+H4d3I7U6d4Wo1sMjEVT6FXqjZ4ylRLwGJrbBCUQY7VjNslGL3i7+kvYld0c7wr WXlCUA78ZIHK5QcA1x8MWyskA7+lFk/DsU9bQyRVk8pJyROO22NrqdoSpA9+wFMvMLCrKOfyJ 9yF/JbsufJsVwH5qSI0InAlkiwxmGLtY1OCSYw7nKfzqV/0I5t6TGe3mZq2Dg062rchN9sO6t tl/6Kvs400/UibnMJ3ulW8DpXpN1rBqUHINDvH5L3EhLWUFzazoeUMRumIf/+DFzeV8eizKKO +y5zU1tw7FjeFdCuwrsrWI/thFiFLnMGG43c/yWlYDOfqVszrSTlmduCY/UPM6qyUw1+BpGDj xQQbmGpXSSKeTQui2FdQIPVzmszcnndcpa86I72KifO1UnQMU25l0rnKvtPsCJt8a96bJ2Kuu ynt0YcuJA+RhZxCV4U2Zn+u4CVE6plMJRx2E9RjfhBOTy4RNB27vOSJtZRbY41Ktr3sUi7/hW PQuemFCVuOtyepfyjdco3drL9wK0CNqocX6e1FDIDjjPq3Gp2DcD9NrAw1ksD/lQzs58VKn5u 3XiMZyAh0xUgUoYP6rs6O/QrQE/uCzn7+9JbY2+0eRloBphzU7fMidFTk4CSIRx5u1mHZxyz1 iW+PGQLcSiRA06urZgv5oGs5XmpPZCvAublHFcDQMUkAxVWe+EpOLc40KpE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21432-done Cc: 21432-done@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> If there's no problem left for w32notify, I believe we can close this bug. > > I don't believe there are any w32notify problems left we know about. So I'm closing the bug. Best regards, Michael. ------------=_1442842864-12883-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 8 Sep 2015 06:36:23 +0000 Received: from localhost ([127.0.0.1]:52073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZCVx-0004Oz-Mk for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34826) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZCVu-0004Oq-Cl for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZCVr-0004p7-Ed for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVr-0004p3-Bm for submit@debbugs.gnu.org; Tue, 08 Sep 2015 02:36:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVo-0000ZJ-DJ for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZCVk-0004nt-9a for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:12 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:50461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCVj-0004nF-SG for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 02:36:08 -0400 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 DB3FA3D6005 for ; Tue, 8 Sep 2015 08:36:06 +0200 (CEST) From: Tassilo Horn To: bug-gnu-emacs@gnu.org Subject: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Date: Tue, 08 Sep 2015 08:36:06 +0200 Message-ID: <87k2s15sfd.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Right now, (at least) the inotify version of `file-notify-rm-watch' signals an error in case the given descriptor denotes a directory which has been deleted in the meantime. If it denotes a file which has been deleted, no error is signaled. Here's a receipe: (require 'filenotify) (let* ((flags '(change)) (handler (lambda () nil)) (file (make-temp-file "foo")) (file-watch (file-notify-add-watch file flags handler)) (dir (make-temp-file "bar" t)) (dir-watch (file-notify-add-watch dir flags handler))) (delete-file file) (delete-directory dir) (file-notify-rm-watch file-watch) ;; works (message "Removed file watch") (file-notify-rm-watch dir-watch) ;; signals an error (message "Removed directory watch")) The documentation does not define any specific behavior for these situation, so this is currently a gray area which makes it hard for package developers to develop something which will work right accross the different notification backends. 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'. In GNU Emacs 25.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-09-08 Repository revision: 6cd64aaf1317bdd96f29fa2a7c3d49172e79bc37 Windowing system distributor 'The X.Org Foundation', version 11.0.11702000 System Description: Arch Linux Configured using: 'configure 'CFLAGS=-g -ggdb3 -O1'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LC_MONETARY: de_DE.utf8 value of $LC_NUMERIC: de_DE.utf8 value of $LC_TIME: de_DE.utf8 value of $LANG: en_US.utf8 locale-coding-system: utf-8-unix Major mode: Group Minor modes in effect: hl-line-mode: t gnus-topic-mode: t global-company-mode: t shell-dirtrack-mode: t global-aggressive-indent-mode: t gnus-undo-mode: t pdf-occur-global-minor-mode: t recentf-mode: t global-subword-mode: t subword-mode: t save-place-mode: t savehist-mode: t show-paren-mode: t ivy-mode: t minibuffer-depth-indicate-mode: t electric-pair-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent messages: 20150908T081715.611> Reading active file via nndraft... 20150908T081715.611> Reading active file via nndraft...done 20150908T081715.612> Reading active file from archive+nnml+archive:sent-postings via nnml... 20150908T081715.612> Opening nnml server on archive+nnml+archive:sent-postings... 20150908T081715.613> Opening nnml server on archive+nnml+archive:sent-postings...done 20150908T081715.615> nnml: Reading incoming mail (no new mail)...done 20150908T081715.615> Reading active file from archive+nnml+archive:sent-postings via nnml... 20150908T081715.616> Reading active file from archive+nnml+archive:sent-postings via nnml...done 20150908T081715.616> Checking new news...done Contacting host: debbugs.gnu.org:80 Load-path shadows: ~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath ~/Repos/el/highlight-symbol.el/highlight-symbol hides /home/horn/.emacs.d/elpa/highlight-symbol-20150816.628/highlight-symbol ~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4 ~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color ~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec ~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache ~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util ~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode ~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig ~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5 ~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm ~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def ~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104 ~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm ~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram ~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns ~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl ~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls ~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc ~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc ~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest ~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode ~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex ~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash ~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock ~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething ~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode ~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util ~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047 ~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml ~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus ~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range ~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int ~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud ~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat ~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh ~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl ~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify ~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar ~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway ~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums ~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse ~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt ~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap ~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft ~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source ~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat ~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3 ~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir ~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader ~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite ~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary ~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary ~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder ~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art ~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon ~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec ~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir ~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial ~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry ~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar ~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface ~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun ~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start ~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley ~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon ~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report ~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp ~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil ~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir ~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr ~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime ~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual ~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications ~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool ~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group ~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg ~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util ~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve ~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft ~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent ~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec ~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark ~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991 ~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231 ~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc ~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo ~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete ~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent ~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7 ~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree ~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu ~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml ~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve ~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus ~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml ~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message ~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime ~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform ~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent ~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic ~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern ~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc ~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage ~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode ~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls ~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired ~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl ~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox ~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win ~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async ~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url ~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html ~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi ~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015 ~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss ~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh ~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum ~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb ~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr ~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix ~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore ~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045 ~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg ~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash ~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score ~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu ~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam ~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view ~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode ~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text ~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems ~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry ~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source ~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar ~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill ~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils ~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap ~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay ~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies ~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive ~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843 ~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill ~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp ~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode ~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic ~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache ~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail ~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm ~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync ~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo ~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry ~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup ~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time ~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date Features: (shadow sort gnus-cite emacsbug sendmail mm-archive crm debbugs-gnu add-log debbugs soap-client url-http url-auth url-gw warnings hl-line nndraft nnmh rot13 utf-7 gnutls network-stream nsm starttls nnml nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg gnus-gravatar mail-extr gravatar gnus-topic nnir gnus-registry registry eieio-compat eieio-base th-private smex ido seq filenotify debug eieio-opt speedbar sb-image ezimage dframe colir color company-files company-oddmuse company-keywords company-etags company-gtags company-dabbrev-code company-dabbrev company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-css company-nxml company-bbdb company stratego-mode greql-mode tg-mode generic preview-latex tex-site auto-loads cider tramp-sh cider-debug cider-browse-ns cider-inspector cider-mode cider-repl cider-eldoc cider-interaction spinner arc-mode archive-mode cider-overlays cider-doc org-table org org-macro org-footnote org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs cider-test cider-stacktrace cider-client cider-util nrepl-client tramp tramp-compat tramp-loaddefs trampver shell pcomplete queue ewoc etags xref project dash clojure-mode paredit aggressive-indent epa-file epa epg rdictcc google-contacts-message google-contacts xml url-cache google-oauth google-contacts-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source password-cache url-vars mailcap nnheader gnus-util dired-x em-term term ehelp esh-opt esh-ext esh-util highlight-symbol thingatpt boxquote rect ecomplete message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-utils gmm-utils mailheader server yasnippet disp-table noutline outline pdf-occur ibuf-ext ibuffer tablist tablist-filter semantic/wisent/comp semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cconv eieio-core mode-local find-func cedet dired pdf-isearch let-alist pdf-misc imenu pdf-tools compile comint ansi-color cus-edit cus-start cus-load pdf-view bookmark pp jka-compr pdf-cache pdf-info tq pdf-util format-spec image-mode browse-kill-ring derived recentf tree-widget wid-edit highlight-parentheses cl iedit iedit-lib cl-extra help-mode hydra lv counsel swiper cap-words superword subword saveplace savehist paren ivy delsel icomplete mb-depth ace-window easy-mmode cl-macs gv avy ring smart-mode-line-respectful-theme smart-mode-line-light-theme cl-seq smart-mode-line rich-minority rx bs elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load subr-x pcase tsdh-light-theme finder-inf memory-usage-autoloads advice info package easymenu epg-config time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 639836 122215) (symbols 48 53035 0) (miscs 40 301 344) (strings 32 164700 67149) (string-bytes 1 5718922) (vectors 16 50490) (vector-slots 8 1133948 17525) (floats 8 961 537) (intervals 56 5318 0) (buffers 976 29) (heap 1024 83217 3736)) ------------=_1442842864-12883-1--