From unknown Wed Aug 20 06:40:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#21435 <21435@debbugs.gnu.org> To: bug#21435 <21435@debbugs.gnu.org> Subject: Status: 25.0.50; file-notify has problems after renames Reply-To: bug#21435 <21435@debbugs.gnu.org> Date: Wed, 20 Aug 2025 13:40:35 +0000 retitle 21435 25.0.50; file-notify has problems after renames reassign 21435 emacs submitter 21435 Tassilo Horn severity 21435 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 04:47:17 2015 Received: (at submit) by debbugs.gnu.org; 8 Sep 2015 08:47:17 +0000 Received: from localhost ([127.0.0.1]:52191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZEYd-0007ow-3w for submit@debbugs.gnu.org; Tue, 08 Sep 2015 04:47:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49523) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZEYa-0007on-5C for submit@debbugs.gnu.org; Tue, 08 Sep 2015 04:47:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZEYX-0006H9-0V for submit@debbugs.gnu.org; Tue, 08 Sep 2015 04:47:11 -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]:37389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZEYW-0006H5-Tp for submit@debbugs.gnu.org; Tue, 08 Sep 2015 04:47:08 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZEYT-0005pn-Ll for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:47:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZEYQ-0006Eq-DA for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:47:05 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:54181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZEYQ-0006EU-11 for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 04:47:02 -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 5E03A3D6006 for ; Tue, 8 Sep 2015 10:47:00 +0200 (CEST) From: Tassilo Horn To: bug-gnu-emacs@gnu.org Subject: 25.0.50; file-notify has problems after renames Date: Tue, 08 Sep 2015 10:47:00 +0200 Message-ID: <87y4gh47sr.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 (-----) file-notify using the inotify backend reports wrong events after directory renames. For example, with (let* ((flags '(change attribute-change)) (handler (lambda (event) (message "WATCH: %S" event))) (x "/tmp/x") (y "/tmp/x/y")) (make-directory x) (make-directory y) (file-notify-add-watch x flags handler) (file-notify-add-watch y flags handler)) the following events are reported after these shell operations: 1. $ touch /tmp/x/y/test1 WATCH: ((12) created "/tmp/x/y/test1") WATCH: ((12) attribute-changed "/tmp/x/y/test1") 2. $ mv /tmp/x/y /tmp/x/z WATCH: ((11) renamed "/tmp/x/y" "/tmp/x/z") [2 times] 3. $ touch /tmp/x/z/test2 WATCH: ((12) created "/tmp/x/y/test2") WATCH: ((12) attribute-changed "/tmp/x/y/test2") In 3, the file created is actually /tmp/x/z/test2, not /tmp/x/y/test2. There is also a problem with single-file watches: (let* ((flags '(change attribute-change)) (handler (lambda (event) (message "WATCH: %S" event))) (x "/tmp/x")) (with-temp-buffer (insert "TEST\n") (write-file x)) (file-notify-add-watch x flags handler)) 1. $ mv /tmp/x /tmp/y WATCH: ((1 . "x") renamed "/tmp/x" "/tmp/y") [2 times] 2. $ echo "more" >> /tmp/y ;; no notification 3. $ touch /tmp/x WATCH: ((1 . "x") created "/tmp/x") WATCH: ((1 . "x") changed "/tmp/x") So in the case of single-file watches, the watch seems to stick to a filename rather than a file. Well, I think that's ok but then I would expect it to be similar with directories, e.g., in the first example step 3 should not report a notification because I intended to watch /tmp/x/y and not /tmp/x/z. Another thing is that renames always seem to be reported twice (although the example in the manual lists only one event but that example has probably gathered with the gfilenotify backend). 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: Lisp Interaction Minor modes in effect: diff-auto-refine-mode: t TeX-PDF-mode: t TeX-source-correlate-mode: t global-company-mode: t company-mode: t shell-dirtrack-mode: t paredit-mode: t global-aggressive-indent-mode: t aggressive-indent-mode: t highlight-symbol-mode: t outline-minor-mode: t pdf-occur-global-minor-mode: t recentf-mode: t highlight-parentheses-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 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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent messages: WATCH: (((10) attribute-changed "/home/horn/x/y/bar")) Auto-saving... WATCH: (((10) created "/home/horn/x/y/foo")) WATCH: (((10) attribute-changed "/home/horn/x/y/foo")) Mark set [2 times] Undo! [10 times] Indenting region...done WATCH: (((10) deleted "/home/horn/x/y/bar")) WATCH: (((10) deleted "/home/horn/x/y/foo")) WATCH: (((9) deleted "/home/horn/x/z")) 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: (tramp-cache flow-fill gnus-fun vc vc-dispatcher vc-git diff-mode texmathp nndoc url-handlers preview prv-emacs auto-dictionary flyspell ispell tex-buf reftex-dcr reftex-auc reftex reftex-vars font-latex latex tex-style tex dbus tex-mode latexenc smiley gnus-bcklg qp gnus-async gnus-ml mailalias smtpmail hippie-exp 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 966399 50632) (symbols 48 59145 97) (miscs 40 580 1231) (strings 32 188617 43232) (string-bytes 1 6426636) (vectors 16 62335) (vector-slots 8 1828918 146254) (floats 8 1054 1533) (intervals 56 7960 3005) (buffers 976 66) (heap 1024 100878 51951)) From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 12:03:36 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 16:03:36 +0000 Received: from localhost ([127.0.0.1]:52831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLMt-00039D-K0 for submit@debbugs.gnu.org; Tue, 08 Sep 2015 12:03:36 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:33464) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLMr-000393-2d for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 12:03:34 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NUD00J0085Z4300@mtaout25.012.net.il> for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 19:00:07 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD00K2C8G77Q00@mtaout25.012.net.il>; Tue, 08 Sep 2015 19:00:07 +0300 (IDT) Date: Tue, 08 Sep 2015 19:03:36 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87y4gh47sr.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83k2s07vaf.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 10:47:00 +0200 > > file-notify using the inotify backend reports wrong events after > directory renames. For example, with > > (let* ((flags '(change attribute-change)) > (handler (lambda (event) > (message "WATCH: %S" event))) > (x "/tmp/x") > (y "/tmp/x/y")) > (make-directory x) > (make-directory y) > (file-notify-add-watch x flags handler) > (file-notify-add-watch y flags handler)) > > the following events are reported after these shell operations: > > 1. $ touch /tmp/x/y/test1 > WATCH: ((12) created "/tmp/x/y/test1") > WATCH: ((12) attribute-changed "/tmp/x/y/test1") > 2. $ mv /tmp/x/y /tmp/x/z > WATCH: ((11) renamed "/tmp/x/y" "/tmp/x/z") [2 times] > 3. $ touch /tmp/x/z/test2 > WATCH: ((12) created "/tmp/x/y/test2") > WATCH: ((12) attribute-changed "/tmp/x/y/test2") > > In 3, the file created is actually /tmp/x/z/test2, not /tmp/x/y/test2. With w32notify, I see something very similar: 1. $ touch /tmp/x/y/test1 WATCH: (133902432 created "d:/tmp/x/y/test1") WATCH: (133902432 changed "d:/tmp/x/y/test1") WATCH: (159542912 changed "d:/tmp/x/y") 2. $ mv /tmp/x/y /tmp/x/z WATCH: (159542912 renamed "d:/tmp/x/y" "d:/tmp/x/z") (Here the watching thread exist with abnormal status.) 3. $ touch /tmp/x/z/test2 WATCH: (133902432 created "d:/tmp/x/y/test2") WATCH: (133902432 changed "d:/tmp/x/y/test2") WATCH: (159542912 changed "d:/tmp/x/z") > There is also a problem with single-file watches: > > (let* ((flags '(change attribute-change)) > (handler (lambda (event) > (message "WATCH: %S" event))) > (x "/tmp/x")) > (with-temp-buffer > (insert "TEST\n") > (write-file x)) > (file-notify-add-watch x flags handler)) > > 1. $ mv /tmp/x /tmp/y > WATCH: ((1 . "x") renamed "/tmp/x" "/tmp/y") [2 times] > 2. $ echo "more" >> /tmp/y > ;; no notification > 3. $ touch /tmp/x > WATCH: ((1 . "x") created "/tmp/x") > WATCH: ((1 . "x") changed "/tmp/x") On Windows: 1. $ mv /tmp/x /tmp/y WATCH: (159487136 renamed "d:/tmp/x" "d:/tmp/x") 2. $ echo "more" >> /tmp/y ;; no notification 3. $ touch /tmp/x WATCH: (159487136 created "d:/tmp/x") WATCH: (159487136 changed "d:/tmp/x") > So in the case of single-file watches, the watch seems to stick to a > filename rather than a file. Well, I think that's ok but then I would > expect it to be similar with directories, e.g., in the first example > step 3 should not report a notification because I intended to watch > /tmp/x/y and not /tmp/x/z. I don't see any problems here. filenotify.el just reports to us what the notification back-end receives. It doesn't (and shouldn't, IMO) include any non-trivial logic to "fix" the back-ends in these tricky cases, because it has no idea what the application will want to do with that. Its role is to present a platform-independent API that uses one of the available back-ends, that's all. IOW, technically, the file/directory you watched disappeared from the filesystem, so what is reported afterwards is IMO entirely resonable at this low level. One application we have on top of filenotify.el is auto-revert.el. Now, if you see some user-level problems there when files are renamed/deleted, please report them. > Another thing is that renames always seem to be reported twice (although > the example in the manual lists only one event but that example has > probably gathered with the gfilenotify backend). This doesn't happen with w32notify. filenotify.el includes some code to produce a single notification out of the 2 reported by back-ends in this case; perhaps something doesn't work there with inotify. Can you step through the code and see why? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 14:04:25 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 18:04:25 +0000 Received: from localhost ([127.0.0.1]:52896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZNFo-00068f-Vg for submit@debbugs.gnu.org; Tue, 08 Sep 2015 14:04:25 -0400 Received: from mout.gmx.net ([212.227.17.22]:63261) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZNFm-00068X-V2 for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 14:04:23 -0400 Received: from detlef.gmx.de ([87.146.58.15]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LyzW8-1YeMqb0nTc-014Cv1; Tue, 08 Sep 2015 20:04:21 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> Date: Tue, 08 Sep 2015 20:04:20 +0200 In-Reply-To: <83k2s07vaf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 19:03:36 +0300") Message-ID: <87fv2ovlcr.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:6r/DgHdK879WAMFA18G+bbYxMeh+qhLiBsI/sy9KTe7rKCmh24P kIivxUNkHsXbXXxbwCsYrpMfjx7c4Hu38uuqFs/Vycc7XxNVOUgyCrVt4KnHcLmXJPdiIHw tozEEuqyeIZM/+O3fcnxf9GErxv5anFxYvwYhQeGppOrhRemVWqFHMfSXIKltbZi0H91i2Y DnJzmIjkFVpAJhWhsRC/g== X-UI-Out-Filterresults: notjunk:1;V01:K0:YPx0goX+o3c=:WhtP9JQrUJdfxRe+x1sjZU hIO/HMBn+Qpx15u22cKGYgtbZmGNZuMPC3finY8W2pbKhm8VzYAWffTlre+RvItre9wo6Tvm7 z/iIxDf8QSqVm/y/a4AITywzscxvf93TMTSMzr4MEEyMBW8lexWmUFWtLgz2dHykPbGzT7928 NMhSoirhPL9x5JdBA83Qn/3oV7Xmk5l4dZper87jMvniG8Q8AoeDjOqcYGVLBsoWdKqPHxeNK aKA/M+WYjP5+PdP0PI2CklJ43MzlHo+z4Mp/S4VK8DYakuecjcqQCneUwW/t6avo+MAaBVYBt B11qjeQl8B2r3FY6O+mhwjxqc/3ZWqr+KxE5Ewd5iUXRh7PgQqVhPQvn7rfLoTletRXGpe2dY yAGU4R/QEnMgKyCV6cj5rMeL8KDqXZyY78DutvtekIB5f6cn5KUJlOe8GvbEY5+UnMUUn18/W DhKgI9OGN98oN7jyONFnAhQPc7OFEoWdtbP9n1/UdqsXxxFCoVu3JT1ST1u9ya4xKoAN85Rsz LMIEy0hbRNaMvZKg0q+0g3f3gkJmkXJ+y+0Jr9g3kckOLipy+635dhCo2PvotRQhAHqYu40Xv cjnMJBJPjPmMmFqsJIBJhM1C7tefSnmVUiNj9DxVNLZniOLcJLOJsFuBz30N2lN4nEkWqC7Wz Kxl0HiGJ4tuGgcGdBedS+fZ5V/NePumI4WCgU+gnFG2MKEz6IwVxwQl27qKsayJmaaNbJtMUT FBnWbnb8sMNx2yxNWL9zcpT6yiJNfZIo0E5vaA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, Tassilo Horn 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: > IOW, technically, the file/directory you watched disappeared from the > filesystem, so what is reported afterwards is IMO entirely resonable > at this low level. Well, inotify sends then the low-level event `delete-self', which is different from the usual `delete'. filenotify.el translates both to the upper-level event `deleted'. In case of `delete-self', filenotify.el could do something more, like removing the watch. Do we want this? > One application we have on top of filenotify.el is auto-revert.el. > Now, if you see some user-level problems there when files are > renamed/deleted, please report them. > >> Another thing is that renames always seem to be reported twice (although >> the example in the manual lists only one event but that example has >> probably gathered with the gfilenotify backend). > > This doesn't happen with w32notify. filenotify.el includes some code > to produce a single notification out of the 2 reported by back-ends in > this case; perhaps something doesn't work there with inotify. Can you > step through the code and see why? Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've changed filenotify.el to fire 2 events `renamed' in case the directories of the source and target are different. This was triggered by a user report, that he wants to have auto-revert-mode for two different directories under dired control. So the event is sent for the two different handlers activated by the respective *-add-watch calls. I've tested for inotify, it works (confirmed by that user). The use case of that user was, that a file has been moved outside Emacs from one directory to the other. An he wanted to see it in both dired buffers, immediately. I couldn't test this for w32notify, but it should behave like this since Sunday. I haven't changed it in gfilenotify yet, it's on my todo list. And the manual must be adapted, as Tassilo has said. Best regards, Michael. PS: Tassilo, you write great test cases. Do you want to contribute to test/automated/file-notify-tests.el? PPS: Forgive me slow progress; I'm still suffering from health problems. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 14:22:17 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 18:22:17 +0000 Received: from localhost ([127.0.0.1]:52936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZNX6-0006a7-Jf for submit@debbugs.gnu.org; Tue, 08 Sep 2015 14:22:17 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:56768) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZNX4-0006Zx-51 for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 14:22:15 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NUD00A00ETK6500@a-mtaout22.012.net.il> for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 21:21:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD009DWEZOKHA0@a-mtaout22.012.net.il>; Tue, 08 Sep 2015 21:21:25 +0300 (IDT) Date: Tue, 08 Sep 2015 21:21:37 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87fv2ovlcr.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83613k7owe.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 , 21435@debbugs.gnu.org > Date: Tue, 08 Sep 2015 20:04:20 +0200 > > Eli Zaretskii writes: > > > IOW, technically, the file/directory you watched disappeared from the > > filesystem, so what is reported afterwards is IMO entirely resonable > > at this low level. > > Well, inotify sends then the low-level event `delete-self', which is > different from the usual `delete'. filenotify.el translates both to the > upper-level event `deleted'. In case of `delete-self', filenotify.el > could do something more, like removing the watch. Do we want this? I don't think filenotify.el should remove the watch on its own, but it could send an event that would allow the application do that if it wants to. > > One application we have on top of filenotify.el is auto-revert.el. > > Now, if you see some user-level problems there when files are > > renamed/deleted, please report them. > > > >> Another thing is that renames always seem to be reported twice (although > >> the example in the manual lists only one event but that example has > >> probably gathered with the gfilenotify backend). > > > > This doesn't happen with w32notify. filenotify.el includes some code > > to produce a single notification out of the 2 reported by back-ends in > > this case; perhaps something doesn't work there with inotify. Can you > > step through the code and see why? > > Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've > changed filenotify.el to fire 2 events `renamed' in case the directories > of the source and target are different. This was triggered by a user > report, that he wants to have auto-revert-mode for two different > directories under dired control. So the event is sent for the two > different handlers activated by the respective *-add-watch calls. But then Tassilo's "renames always seem to be reported twice" is inaccurate: this should only happen when a file is moved to another directory. > I've tested for inotify, it works (confirmed by that user). The use case > of that user was, that a file has been moved outside Emacs from one > directory to the other. An he wanted to see it in both dired buffers, > immediately. > > I couldn't test this for w32notify, but it should behave like this since > Sunday. If you can show some simple test case, I can run it. > PPS: Forgive me slow progress; I'm still suffering from health problems. Wish you to recover quickly. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 15:05:09 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 19:05:09 +0000 Received: from localhost ([127.0.0.1]:52964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOCa-0007aX-QR for submit@debbugs.gnu.org; Tue, 08 Sep 2015 15:05:09 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:54976) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOCZ-0007aP-1o for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 15:05:08 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 785EC208B9 for <21435@debbugs.gnu.org>; Tue, 8 Sep 2015 15:05:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 08 Sep 2015 15:05:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=G92dGBMR+3S8ztEdX3gRGYRm434=; b=uIuHryTEG2UdaqWpKf1T 1YPJKNGcnP99LBbxreaxSU86xatNyQy7A0P3CFBg4P6hgZhRm129Q+x1XkClFxmd 7tr05mo8rTMk6IrdKnDwhprBlgPkKsHJf6/70fLBFAsOi9VUA9EPsmPb4pqWVVQE 5cxijIszN13pecyafikrVAg= X-Sasl-enc: 0gnZvWXtgDFbJVx8+YgQiDbm/JB7FjYnyfq0Qrb3OuiO 1441739104 Received: from thinkpad-t440p (unknown [2.163.188.161]) by mail.messagingengine.com (Postfix) with ESMTPA id A87BDC0028A; Tue, 8 Sep 2015 15:05:02 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> Date: Tue, 08 Sep 2015 21:05:00 +0200 Message-ID: <87wpw0g2ar.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-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.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.3 (/) Eli Zaretskii writes: >> Another thing is that renames always seem to be reported twice >> (although the example in the manual lists only one event but that >> example has probably gathered with the gfilenotify backend). > > This doesn't happen with w32notify. filenotify.el includes some code > to produce a single notification out of the 2 reported by back-ends in > this case; perhaps something doesn't work there with inotify. Can you > step through the code and see why? I stepped through inotify_callback in inotify.c which can read 64 byte from inotifyfd where the size of one inotify event is 32 and that produces 2 emacs events (although I cannot see which events are created). The Locals GUD frame always shows just nil for the `event' local variable even after the assignments to it and I stepped into the then-branch of an `if (!NILP(event.arg))' which makes it pretty clear that it cannot be nil. Why is that? Then I turned to `file-notify-callback'. That receives one `move-from' event and one `move-to' event which I figured out by adding a message. The problem is that as soon as I edebug the function, I can only see the first call for the `mode-from' event. After stepping through it, I won't be put into the debugger for the second event as if it has been discarded in the meantime. My handle function is also not run when edebugging. Is that expected that when edebugging event handlers one might miss events? Anyway, eventually I found and fixed the culprit which simply was that the watch descriptors of the pending and the current event were compared with `eq' which is not valid because inotify descriptors are conses. I've changed the comparison to `equal' which fixes the double-reporting issue. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 15:19:30 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 19:19:30 +0000 Received: from localhost ([127.0.0.1]:52972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOQT-0007v4-Sb for submit@debbugs.gnu.org; Tue, 08 Sep 2015 15:19:30 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:42629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOQR-0007uu-2V for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 15:19:28 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NUD00K00H88AY00@a-mtaout21.012.net.il> for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 22:19:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD00K7MHOD8G80@a-mtaout21.012.net.il>; Tue, 08 Sep 2015 22:19:25 +0300 (IDT) Date: Tue, 08 Sep 2015 22:19:38 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87wpw0g2ar.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <831te87m7p.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87wpw0g2ar.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: 21435@debbugs.gnu.org > Date: Tue, 08 Sep 2015 21:05:00 +0200 > > I stepped through inotify_callback in inotify.c which can read 64 byte > from inotifyfd where the size of one inotify event is 32 and that > produces 2 emacs events (although I cannot see which events are > created). The Locals GUD frame always shows just nil for the `event' > local variable even after the assignments to it and I stepped into the > then-branch of an `if (!NILP(event.arg))' which makes it pretty clear > that it cannot be nil. Why is that? Could be some gud bug. Do you see the same when you invoke GDB from the shell? > Then I turned to `file-notify-callback'. That receives one `move-from' > event and one `move-to' event which I figured out by adding a message. > The problem is that as soon as I edebug the function, I can only see the > first call for the `mode-from' event. After stepping through it, I > won't be put into the debugger for the second event as if it has been > discarded in the meantime. My handle function is also not run when > edebugging. Is that expected that when edebugging event handlers one > might miss events? I always use 'message' when debugging event-driven code. I just don't trust edebug enough in these cases. > Anyway, eventually I found and fixed the culprit which simply was that > the watch descriptors of the pending and the current event were compared > with `eq' which is not valid because inotify descriptors are conses. > I've changed the comparison to `equal' which fixes the double-reporting > issue. Thanks. But meanwhile Michale explained that this behavior was on purpose, due to a recent change. Do you see 2 events only when a file was moved to a different directory, or also when it is renamed in the same directory? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 15:28:22 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 19:28:22 +0000 Received: from localhost ([127.0.0.1]:52981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOZ3-00087p-Ha for submit@debbugs.gnu.org; Tue, 08 Sep 2015 15:28:22 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51556) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOZ1-00087h-Dn for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 15:28:19 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 50C35209E0 for <21435@debbugs.gnu.org>; Tue, 8 Sep 2015 15:28:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 08 Sep 2015 15:28:19 -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=cBopHAI+mMyjp11bga1HkNkghwQ=; b=fiPWh Vwtw1qgVyeSK58cJTg/UgnUDdKBaLhEZnorx/jH24i0TPfWVeKMdZUeMab3L98zP nSbUmIZWkxYKgNeM+E9Otwvby/k5un2JS1Ggk78yeaGWyurvvOWb1H/jXHzukFD1 NgJxM5S9s2ievgBCBRKP1CvDXAyxXF0lfAYEVs= X-Sasl-enc: FC3K/AtNB7cUa/fVM33LzPlBcmBlXbgxUw8DLhRwUHsJ 1441740498 Received: from thinkpad-t440p (unknown [2.163.188.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 7973CC00020; Tue, 8 Sep 2015 15:28:18 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> Date: Tue, 08 Sep 2015 21:28:16 +0200 In-Reply-To: <83613k7owe.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 21:21:37 +0300") Message-ID: <87si6og17z.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-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, Michael Albinus 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: >> Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've >> changed filenotify.el to fire 2 events `renamed' in case the >> directories of the source and target are different. This was >> triggered by a user report, that he wants to have auto-revert-mode >> for two different directories under dired control. So the event is >> sent for the two different handlers activated by the respective >> *-add-watch calls. > > But then Tassilo's "renames always seem to be reported twice" is > inaccurate: this should only happen when a file is moved to another > directory. See my other mail: the test if the source/target are different were done by testing if the descriptors are not `eq' but since inotify descriptors are conses, that test returned nil even though they were structurally equal. >> PS: Tassilo, you write great test cases. Do you want to contribute to >> test/automated/file-notify-tests.el? Yes, but right now I can't because all these corner cases like the ones from my last two reports are largely undocumented so I don't know what to assert. I myself don't have a strong opinion on the behavior of file-notify as long as it's consistent across the different `file-notify--library' possibilities (at least mostly, e.g., I can live with created/deleted events in place of renamed in case the backend doesn't support this) and the documentation is a bit more definite. >> PPS: Forgive me slow progress; I'm still suffering from health >> problems. > > Wish you to recover quickly. Ditto! Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 15:47:58 2015 Received: (at 21435) by debbugs.gnu.org; 8 Sep 2015 19:47:58 +0000 Received: from localhost ([127.0.0.1]:52985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOs1-0000Be-KD for submit@debbugs.gnu.org; Tue, 08 Sep 2015 15:47:57 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:45999) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOrz-0000BW-9s for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 15:47:56 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7ED1320CCF for <21435@debbugs.gnu.org>; Tue, 8 Sep 2015 15:47:53 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 08 Sep 2015 15:47:53 -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=GOgrYJ6+dJlW3kmnxDkPk4uuPt4=; b=NBMw8 e6vXdqD8Bg/Az8GJyUICJxEnO/XqGbTVZwtVA8Qc+HWyWobAWqeFFbjPK61pzB8c 9g3xZ5mNXkOOfYq34Y/zR2CjiC2v3wqgF6vWcCCWYvTYzyN80zOeCxh4HCmT3tee E/uI/Q+0gJsGw+gg4emsxj+zmziP7XLaPKhfqE= X-Sasl-enc: X2D3Fz3DjezEXbHKIMJI/iPmpK0+t5YMNJoTQzlGnjYv 1441741673 Received: from thinkpad-t440p (unknown [2.163.188.161]) by mail.messagingengine.com (Postfix) with ESMTPA id C7789C00285; Tue, 8 Sep 2015 15:47:52 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87wpw0g2ar.fsf@gnu.org> <831te87m7p.fsf@gnu.org> Date: Tue, 08 Sep 2015 21:47:50 +0200 In-Reply-To: <831te87m7p.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 22:19:38 +0300") Message-ID: <87oahcg0bd.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-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.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.3 (/) Eli Zaretskii writes: >> I stepped through inotify_callback in inotify.c which can read 64 >> byte from inotifyfd where the size of one inotify event is 32 and >> that produces 2 emacs events (although I cannot see which events are >> created). The Locals GUD frame always shows just nil for the `event' >> local variable even after the assignments to it and I stepped into >> the then-branch of an `if (!NILP(event.arg))' which makes it pretty >> clear that it cannot be nil. Why is that? > > Could be some gud bug. Do you see the same when you invoke GDB from > the shell? Oh, my GDB foo on the command line ends with making backtraces. ;-) But just typing in "info locals" in the *gud-bootstrap-emacs* buffer is about the same, no? And that shows event = {kind = FILE_NOTIFY_EVENT, part = scroll_bar_nowhere, code = 0, modifiers = 0, x = 0, y = 0, timestamp = 0, frame_or_window = 0, arg = 0} whereas the relevant line in the locals GUD window is just struct input_event event nil So that looks like a bug. I guess I should report this, or will you fix this right now? >> Is that expected that when edebugging event handlers one might miss >> events? > > I always use 'message' when debugging event-driven code. I just don't > trust edebug enough in these cases. Ok. >> Anyway, eventually I found and fixed the culprit which simply was >> that the watch descriptors of the pending and the current event were >> compared with `eq' which is not valid because inotify descriptors are >> conses. I've changed the comparison to `equal' which fixes the >> double-reporting issue. > > Thanks. But meanwhile Michale explained that this behavior was on > purpose, due to a recent change. Do you see 2 events only when a file > was moved to a different directory, or also when it is renamed in the > same directory? When renaming in the same directory. I think Michaels case is where you move a file from watched directory A to watched directory B, and then you want the rename event reported to both handlers. The case I fixed is just that both source and target watch descriptor are actually the same but not identical Lisp objects. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 22:39:25 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 02:39:26 +0000 Received: from localhost ([127.0.0.1]:53150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZVID-0003It-Fw for submit@debbugs.gnu.org; Tue, 08 Sep 2015 22:39:25 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:53962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZVIA-0003Ih-2b for 21435@debbugs.gnu.org; Tue, 08 Sep 2015 22:39:23 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NUE00L001QH8200@a-mtaout21.012.net.il> for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 05:39:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUE00LTH21J7A10@a-mtaout21.012.net.il>; Wed, 09 Sep 2015 05:39:20 +0300 (IDT) Date: Wed, 09 Sep 2015 05:39:34 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87oahcg0bd.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83zj0w5na1.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87wpw0g2ar.fsf@gnu.org> <831te87m7p.fsf@gnu.org> <87oahcg0bd.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: 21435@debbugs.gnu.org > Date: Tue, 08 Sep 2015 21:47:50 +0200 > > Eli Zaretskii writes: > > >> I stepped through inotify_callback in inotify.c which can read 64 > >> byte from inotifyfd where the size of one inotify event is 32 and > >> that produces 2 emacs events (although I cannot see which events are > >> created). The Locals GUD frame always shows just nil for the `event' > >> local variable even after the assignments to it and I stepped into > >> the then-branch of an `if (!NILP(event.arg))' which makes it pretty > >> clear that it cannot be nil. Why is that? > > > > Could be some gud bug. Do you see the same when you invoke GDB from > > the shell? > > Oh, my GDB foo on the command line ends with making backtraces. ;-) > > But just typing in "info locals" in the *gud-bootstrap-emacs* buffer is > about the same, no? And that shows > > event = {kind = FILE_NOTIFY_EVENT, part = scroll_bar_nowhere, code = 0, modifiers = 0, x = 0, y = 0, timestamp = 0, frame_or_window = 0, arg = 0} > > whereas the relevant line in the locals GUD window is just > > struct input_event event nil > > So that looks like a bug. I guess I should report this, or will you fix > this right now? Please report it, with a test case. A C struct can never be nil, so this is a clear bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 02:13:22 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 06:13:22 +0000 Received: from localhost ([127.0.0.1]:53228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZYdG-0008Og-Dz for submit@debbugs.gnu.org; Wed, 09 Sep 2015 02:13:22 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:48961) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZYdE-0008OY-55 for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 02:13:21 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6231220A2F for <21435@debbugs.gnu.org>; Wed, 9 Sep 2015 02:13:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 09 Sep 2015 02:13:18 -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=lHimtdQ0OFD5cpKIGud7/K8YJp8=; b=lrU00 /ftRVryp2DPMT7g5Mq7777IPbtCybd8YIy4jPPONYtL0yl6Agg0KatLB/MzaUVWf Hqh7G91RH9TD9eaYMtqF6PWsBh25SHYIroMfKEqNlpxUVnePq/7CrHrXrNrCTDCm jRnkNkBpZrWlcCCTNZ5XvJqnYYZwY3IGlbTw0Q= X-Sasl-enc: w5PsGxmcHbP/KJnYktMaVQ6y+GRrEoJKlPMAhBt7bz+P 1441779197 Received: from thinkpad-t440p (unknown [2.161.206.107]) by mail.messagingengine.com (Postfix) with ESMTPA id AA9C16800F7; Wed, 9 Sep 2015 02:13:17 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87wpw0g2ar.fsf@gnu.org> <831te87m7p.fsf@gnu.org> <87oahcg0bd.fsf@gnu.org> <83zj0w5na1.fsf@gnu.org> Date: Wed, 09 Sep 2015 08:13:15 +0200 In-Reply-To: <83zj0w5na1.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 09 Sep 2015 05:39:34 +0300") Message-ID: <87vbbkazno.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-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.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.3 (/) Eli Zaretskii writes: >> But just typing in "info locals" in the *gud-bootstrap-emacs* buffer is >> about the same, no? And that shows >> >> event = {kind = FILE_NOTIFY_EVENT, part = scroll_bar_nowhere, code = 0, >> modifiers = 0, x = 0, y = 0, timestamp = 0, frame_or_window = 0, arg = 0} >> >> whereas the relevant line in the locals GUD window is just >> >> struct input_event event nil >> >> So that looks like a bug. I guess I should report this, or will you fix >> this right now? > > Please report it, with a test case. A C struct can never be nil, so > this is a clear bug. Done: bug#21438. But it actually seems to be intentional. GUD uses the --simple-values option when getting the values of the locals, and then all variables of complex types have no value and nil is printed. Well, in the report I suggest to use something like instead to make it obvious that the value is not nil but simply not displayed. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 14:15:15 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 18:15:15 +0000 Received: from localhost ([127.0.0.1]:54129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZjtq-00050G-Ik for submit@debbugs.gnu.org; Wed, 09 Sep 2015 14:15:15 -0400 Received: from mout.gmx.net ([212.227.15.15]:63936) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZjtp-000508-0N for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 14:15:13 -0400 Received: from detlef.gmx.de ([87.146.52.139]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LvVYZ-1Yb03x1UUl-010ZP2; Wed, 09 Sep 2015 20:15:10 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> Date: Wed, 09 Sep 2015 20:15:09 +0200 In-Reply-To: <87si6og17z.fsf@gnu.org> (Tassilo Horn's message of "Tue, 08 Sep 2015 21:28:16 +0200") Message-ID: <877fnzv4r6.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:TbfL9kpThNrnhYTJRVwSzbBAZmM9sZuqHslNDf18lj3HmcPCmr0 ErxKUC7wdj7W75zZ2i/0LmBm5dVEaJJWYJ7rYmC0KTxupphVJufWTiISA3xQrbjPnS7upwZ 1U7qaEapMVyOXqdGnz5O+klzl8dB3YHFPx7ycPGKIU7PSJr7etriyc1UgrXPptq+wAXEygd wu27fKo3IC2Gq4xLgWBfQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TQPEXYl3Gag=:U/8rRq7wBMfQzrMZ5B34+B YnQ94QJMw4lVQiQI0772ENpUxDAVBnB+LrjRFVLLlaglOoYq4Yuar74aEFIuhDee3RqvbKMW9 HFutgAwsIrX73H0oW/lRrMQr8Z/tR3HE2ZNaRdhZlsekq7kJiprfoMzHw+9JzIMVYbNXp2woB OJn+SJXNpPqRt2cfriJoDMcLGLVxlC00IvdfNhcSbd1MWYqwoTbjl4sK2w/0g/O+Jz55CE6Ex DF1Yv7GXVErOSn8G6q3YVbfzvm1YhKzIukHRLUI4rtdYpcpdk/mRndhm7L4t/ZL/LP31VioV/ aYTMcIpbqaqFuemnNmuWZ44TFM3rK7APMrcvF7HyGCeHwENmK2p94HbWmt4ScYBUCXaEFVjmR GiZtdrD1CBqXKr6amoi94e0pLZq3cI9qV5bLzR/3z1FpBtObQNsnNsZ+WNvrMM8Zbk7/RtZ07 89wUBrbo5NFSZXG8FzLNVbCZy2SA9HY0SC91WmPBGy5aYgclxR5aaRbCcg4gRCH6ZDgDm+i3I qmlJvOR4aB1pAUl3UTgcYBPGRsvvicV9vJK6kyQiwzUvd2+/qSnG2nCjOkrzvNG90vPQYMond Ris9sx2ubeTzjHM9slFES9klUMOUXqWLnWrUVpeTIOQbRPJQr6fdiJG3OHQ4ZxbxOtX/RBZzx r2ODDWlFujLQEf+mSDVQ7gKyaqDBHXlwz9KMREIx7+gLQ8q6SL51ecZ1RRGmDYqEGjxi6zVTI XRa2SSNoGjn41OdIKOHeCKEIFGAeFY5pnDyn2Q== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Tassilo Horn writes: >> But then Tassilo's "renames always seem to be reported twice" is >> inaccurate: this should only happen when a file is moved to another >> directory. > > See my other mail: the test if the source/target are different were done > by testing if the descriptors are not `eq' but since inotify descriptors > are conses, that test returned nil even though they were structurally > equal. Thanks for fixing this. I always had in mind that `file-notify--descriptor' returns the same object, and maybe it did even so in the past, but now it composes the cons itself. So we must test for `equal', indeed. >>> PS: Tassilo, you write great test cases. Do you want to contribute to >>> test/automated/file-notify-tests.el? > > Yes, but right now I can't because all these corner cases like the ones > from my last two reports are largely undocumented so I don't know what > to assert. I myself don't have a strong opinion on the behavior of > file-notify as long as it's consistent across the different > `file-notify--library' possibilities (at least mostly, e.g., I can live > with created/deleted events in place of renamed in case the backend > doesn't support this) and the documentation is a bit more definite. Even the straigt forward cases are not covered well in file-notify-tests.el. There is a test whether events arrive, but the nature of the events is not asserted. You could try with what you expect, at least for inotify, and Eli and I could check then for the gfilenotify and w32notify cases. If we have the same results, fine; if we have different results it would be a good chance for us to harmonize. And starting with inotify is also good because this is the library used on hydra. We do not want to make Glenn sad because of failed tests. >>> PPS: Forgive me slow progress; I'm still suffering from health >>> problems. >> >> Wish you to recover quickly. > > Ditto! Won't happen, unfortunately. It still takes months. > Bye, > Tassilo Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 14:42:01 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 18:42:01 +0000 Received: from localhost ([127.0.0.1]:54133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkJk-0005tI-Oy for submit@debbugs.gnu.org; Wed, 09 Sep 2015 14:42:01 -0400 Received: from mout.gmx.net ([212.227.17.20]:55592) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkJi-0005t9-8A for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 14:41:58 -0400 Received: from detlef.gmx.de ([87.146.52.139]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MOBOi-1ZWQOP0Qya-005X6q; Wed, 09 Sep 2015 20:41:57 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> Date: Wed, 09 Sep 2015 20:41:55 +0200 In-Reply-To: <83613k7owe.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 21:21:37 +0300") Message-ID: <8737ynv3ik.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:Q4OLP1UhE5QhOBXDZSGrdZKbD/triF5iACfmBeKodWYibzOhjgB McKm/cFeZAK5rIFiO+brQZ6DuUclFjPxUu42fkV7SpLE7BMx4BqXojFSdLAgEu7u3RImBNj WWkxmT0QWVVP51SVvyqLq5KxSeAXEua+u/yDBlTqZQWPlzLE9LkT5yDe45+navSxvz1Fd6y cSdQQRMWuvrzLGB8VpBSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:xMI3hUWz4ho=:FcK/g+6qk9XaweURni0s+r VDsAxId4NOAZdj5ztvw3efRioAjUpB9fvnh7uIKUXALNpeIeeoYQr71OrOp67Xhgd8vrDaP5u AHLuBiUnHXkKIiSGT/k65WRM3JIdPKNlC0uKx44QdjrUAZIgcoip3PyYVzhn3uxR41gw7sfIP GoCUL/0l7jYXox19llEzpK7lniaZ5gcdVtgp5FwDXb5LnZBBXVsYwACcNl2n3WIqwL+NXXXO2 5ZiNKfOXi8jQ3IvzvDGZGdTzJR8C3w8e17ivrIBuL1FrKgZPjXeokdwAuJrrb7vfbZJV5NetU l2lQNbjaGiwLQ+9m8HPz193mlRrSDYHIc53Q0QaHB2Yi8iOqfh1gRMg9wvfnOSN9VH16rCmoi ZlXCRdYblunCrHY8/W23r7k2u14Ok8JovQxtB9iEG4AWUL8eHwXBqdK1x5xLnLnhkU41eak8Q QbzmuI6OpqCXZYbsyCHa1GzjRdP2skh+px5sdOto3q8BTv5uIzRj0vI+GVGfEr0ms8qnvAeQz iAK3Lo3qsQV1fW9P43Vsy32jA9xV/fPdV6pUpoB7+O4KJz+dqu6Dcy74FRlB/bfNbnbSQ+bBX uboYN7K36Haxb/8LeQ+xVeZhgend0EFS0u5jVC7+SgxQOtZhTlc04hfM0gieuBMr/p0T7UUNm mZnHD4U+mPgxD2d7hR2AtGCccAjX+pkrh2RhIv53ZaKblgo/xN1Bc3TN7Wd7B78Z4I/L4dXvZ Ij45tMBD24Fh+OdDuLBOEY6U2QuzHU3MLgLJQg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: >> Well, inotify sends then the low-level event `delete-self', which is >> different from the usual `delete'. filenotify.el translates both to the >> upper-level event `deleted'. In case of `delete-self', filenotify.el >> could do something more, like removing the watch. Do we want this? > > I don't think filenotify.el should remove the watch on its own, but it > could send an event that would allow the application do that if it > wants to. I will think about. And check also what's possible with gfilenotify. >> I've tested for inotify, it works (confirmed by that user). The use case >> of that user was, that a file has been moved outside Emacs from one >> directory to the other. An he wanted to see it in both dired buffers, >> immediately. >> >> I couldn't test this for w32notify, but it should behave like this since >> Sunday. > > If you can show some simple test case, I can run it. Well, something like this: --8<---------------cut here---------------start------------->8--- (progn (require 'filenotify) (defalias 'myhandler1 'ignore) (defalias 'myhandler2 'ignore) (file-notify-add-watch "/tmp" '(change) 'myhandler1) (file-notify-add-watch "~/tmp" '(change) 'myhandler2) (trace-function 'file-notify-handle-event) (trace-function 'myhandler1) (trace-function 'myhandler2)) --8<---------------cut here---------------end--------------->8--- Then you do outside Emacs (inotify case): --8<---------------cut here---------------start------------->8--- # echo xxx >/tmp/xxx ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (create) "xxx" 0) file-notify-callback)) | 2 -> (myhandler1 ((1) created "/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (modify) "xxx" 0) file-notify-callback)) | 2 -> (myhandler1 ((1) changed "/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil # mv /tmp/xxx ~/tmp/ ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (moved-from) "xxx" 49278) file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (2 (moved-to) "xxx" 49278) file-notify-callback)) | 2 -> (myhandler1 ((1) renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) | 2 <- myhandler1: nil | 2 -> (myhandler2 ((2) renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) | 2 <- myhandler2: nil 1 <- file-notify-handle-event: nil --8<---------------cut here---------------end--------------->8--- That looks good. The same scenario for gfilenotify needs some improvements: --8<---------------cut here---------------start------------->8--- # echo xxx >/tmp/xxx ====================================================================== 1 -> (file-notify-handle-event (file-notify (3924112 created "/tmp/xxx") file-notify-callback)) | 2 -> (myhandler1 (3924112 created "/tmp/xxx")) | 2 <- myhandler1: nil | 2 -> (myhandler1 (3924112 created "/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (3924112 changed "/tmp/xxx") file-notify-callback)) | 2 -> (myhandler1 (3924112 changed "/tmp/xxx")) | 2 <- myhandler1: nil | 2 -> (myhandler1 (3924112 changed "/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (3924112 changes-done-hint "/tmp/xxx") file-notify-callback)) 1 <- file-notify-handle-event: nil # mv /tmp/xxx ~/tmp/ ====================================================================== 1 -> (file-notify-handle-event (file-notify (3924112 moved "/tmp/xxx" "/home/albinus/tmp/xxx") file-notify-callback)) | 2 -> (myhandler1 (3924112 renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) | 2 <- myhandler1: nil | 2 -> (myhandler1 (3924112 renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil --8<---------------cut here---------------end--------------->8--- myhandler1 is always called twice (why?). And in the rename case, the call of myhandler2 is missing. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 15:01:24 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 19:01:24 +0000 Received: from localhost ([127.0.0.1]:54137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkcW-0006MK-15 for submit@debbugs.gnu.org; Wed, 09 Sep 2015 15:01:24 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:34013) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkcU-0006MC-97 for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 15:01:23 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9CD1B20ABD for <21435@debbugs.gnu.org>; Wed, 9 Sep 2015 15:01:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 09 Sep 2015 15:01:21 -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=sUy3USdC1DXQiRDYhY85nYxsDKM=; b=hwvWW BSqtE+OfbtZI5c8rzLhj6sRudZMK+NUU56jwa4xSoDvs57lW8Cs5eUBRdPbNt6Eq aWerYyNkEd13bYoHs5tjjzgyPWzyjDH6WhgJlHtcd9PIGBAWy0+bEwVcM6yzUfYh W65OivYL3Ywes99GQkbQ1wz2J3WmtOKklux38U= X-Sasl-enc: K+oCGoiw5m3Lb56Ol4b84CzW6Y57w0USzN7eZ3KQpQW8 1441825281 Received: from thinkpad-t440p (unknown [2.161.206.107]) by mail.messagingengine.com (Postfix) with ESMTPA id D5D93680137; Wed, 9 Sep 2015 15:01:20 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> Date: Wed, 09 Sep 2015 21:01:18 +0200 In-Reply-To: <877fnzv4r6.fsf@gmx.de> (Michael Albinus's message of "Wed, 09 Sep 2015 20:15:09 +0200") Message-ID: <87egi7o1s1.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Michael Albinus writes: >>>> PS: Tassilo, you write great test cases. Do you want to contribute >>>> to test/automated/file-notify-tests.el? >> >> Yes, but right now I can't because all these corner cases like the ones >> from my last two reports are largely undocumented so I don't know what >> to assert. I myself don't have a strong opinion on the behavior of >> file-notify as long as it's consistent across the different >> `file-notify--library' possibilities (at least mostly, e.g., I can live >> with created/deleted events in place of renamed in case the backend >> doesn't support this) and the documentation is a bit more definite. > > Even the straigt forward cases are not covered well in > file-notify-tests.el. There is a test whether events arrive, but the > nature of the events is not asserted. > > You could try with what you expect, at least for inotify, and Eli and > I could check then for the gfilenotify and w32notify cases. If we have > the same results, fine; if we have different results it would be a > good chance for us to harmonize. That's right. I'll try adding some tests whenever I find some time. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 15:21:29 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 19:21:30 +0000 Received: from localhost ([127.0.0.1]:54203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkvx-0006rH-Eq for submit@debbugs.gnu.org; Wed, 09 Sep 2015 15:21:29 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:50411) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZkvu-0006r8-Eb for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 15:21:27 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NUF00I00C2V0300@mtaout29.012.net.il> for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 22:21:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUF00DMXCGACN50@mtaout29.012.net.il>; Wed, 09 Sep 2015 22:21:46 +0300 (IDT) Date: Wed, 09 Sep 2015 22:21:17 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <8737ynv3ik.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83h9n35rgy.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Wed, 09 Sep 2015 20:41:55 +0200 > > >> I couldn't test this for w32notify, but it should behave like this since > >> Sunday. > > > > If you can show some simple test case, I can run it. > > Well, something like this: > > --8<---------------cut here---------------start------------->8--- > (progn > (require 'filenotify) > (defalias 'myhandler1 'ignore) > (defalias 'myhandler2 'ignore) > (file-notify-add-watch "/tmp" '(change) 'myhandler1) > (file-notify-add-watch "~/tmp" '(change) 'myhandler2) > (trace-function 'file-notify-handle-event) > (trace-function 'myhandler1) > (trace-function 'myhandler2)) > --8<---------------cut here---------------end--------------->8--- > > Then you do outside Emacs (inotify case): > > --8<---------------cut here---------------start------------->8--- > # echo xxx >/tmp/xxx > > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (1 (create) "xxx" 0) file-notify-callback)) > | 2 -> (myhandler1 ((1) created "/tmp/xxx")) > | 2 <- myhandler1: nil > 1 <- file-notify-handle-event: nil > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (1 (modify) "xxx" 0) file-notify-callback)) > | 2 -> (myhandler1 ((1) changed "/tmp/xxx")) > | 2 <- myhandler1: nil > 1 <- file-notify-handle-event: nil This behaves the same on w32: ====================================================================== 1 -> (file-notify-handle-event (file-notify (100286560 added "xxx") file-notify-callback)) | 2 -> (myhandler1 (100286560 created "d:/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100286560 modified "xxx") file-notify-callback)) | 2 -> (myhandler1 (100286560 changed "d:/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil > # mv /tmp/xxx ~/tmp/ > > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (1 (moved-from) "xxx" 49278) file-notify-callback)) > 1 <- file-notify-handle-event: nil > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (2 (moved-to) "xxx" 49278) file-notify-callback)) > | 2 -> (myhandler1 ((1) renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) > | 2 <- myhandler1: nil > | 2 -> (myhandler2 ((2) renamed "/tmp/xxx" "/home/albinus/tmp/xxx")) > | 2 <- myhandler2: nil > 1 <- file-notify-handle-event: nil > --8<---------------cut here---------------end--------------->8--- > > That looks good. This doesn't work at all on w32 (I used d:/usr/eli/data instead of ~/tmp), it reports removal and addition (and also a bogus 2nd removal): ====================================================================== 1 -> (file-notify-handle-event (file-notify (100286608 removed "xxx") file-notify-callback)) | 2 -> (myhandler2 (100286608 deleted "d:/usr/eli/data/xxx")) | 2 <- myhandler2: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100286608 added "xxx") file-notify-callback)) | 2 -> (myhandler2 (100286608 created "d:/usr/eli/data/xxx")) | 2 <- myhandler2: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100286560 removed "xxx") file-notify-callback)) | 2 -> (myhandler1 (100286560 deleted "d:/tmp/xxx")) | 2 <- myhandler1: nil 1 <- file-notify-handle-event: nil Let me know what I should look into or which additional information I can give you about this. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 16:23:12 2015 Received: (at 21435) by debbugs.gnu.org; 9 Sep 2015 20:23:13 +0000 Received: from localhost ([127.0.0.1]:54229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZltg-0000AD-Dq for submit@debbugs.gnu.org; Wed, 09 Sep 2015 16:23:12 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:48810) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZlte-0000A3-Km for 21435@debbugs.gnu.org; Wed, 09 Sep 2015 16:23:11 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3E1F2201E3 for <21435@debbugs.gnu.org>; Wed, 9 Sep 2015 16:23:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 09 Sep 2015 16:23:09 -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=v2mjNlnq5UaKL9ztOIvTMMt/mGM=; b=f4jcs eX4KWKnSDe4SJAlFxGPWK/YBL8n9A7bKumH3Fu5RpGmVfzOdjhh7Gxq+Jq7i2N+d RW2aReSvQYtEXPnrrQpFGCbOBKsdQF9WolUeTu66nkkyfmvxJ4oZmQSoRJWUO3Wl 2ElXQmiw41sTHK0JN7scUb9+CCaOPXF+H4bWcM= X-Sasl-enc: EziZOoRMfvNozVgfPADMslJPKbUOvU+hFx2clt8GTg25 1441830188 Received: from thinkpad-t440p (unknown [2.161.206.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F83DC00020; Wed, 9 Sep 2015 16:23:08 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> Date: Wed, 09 Sep 2015 22:23:05 +0200 In-Reply-To: <87egi7o1s1.fsf@gnu.org> (Tassilo Horn's message of "Wed, 09 Sep 2015 21:01:18 +0200") Message-ID: <871te7tk9i.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Tassilo Horn writes: >> Even the straigt forward cases are not covered well in >> file-notify-tests.el. There is a test whether events arrive, but the >> nature of the events is not asserted. >> >> You could try with what you expect, at least for inotify, and Eli and >> I could check then for the gfilenotify and w32notify cases. If we >> have the same results, fine; if we have different results it would be >> a good chance for us to harmonize. > > That's right. I'll try adding some tests whenever I find some time. Ok, I gave it a whirl and now the `file-notify--test-event-handler' also records all events in a new variable `file-notify--test-events' for later analysis. `file-notify-test02-events' now uses that feature to check if the received events are the expected ones in the expected order. That already revealed two problems: 1. Now `file-notify-test02-events-remote' fails because after every expected `changed' event an additional `attribute-changed' event is received. This is wrong because when adding the watch, only '(change) is given as FLAGS argument, not '(change attribute-change). 2. When I change the watch FLAGS to '(change attribute-change), there are still no attribute-changed events received in the local case. And a question: Will the events read by `file-notify--wait-for-events' still be processed by the handler function? And what's the intention of (file-notify--wait-for-events 5 file-notify--test-results)? The timeout of 5 is reasonable, but the UNTIL argument here just defines that it waits until the very first of possibly up to nine yet missing events is awaited here, or do I get something wrong? Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 07:09:41 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 11:09:41 +0000 Received: from localhost ([127.0.0.1]:54541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZzjY-0005ah-Ls for submit@debbugs.gnu.org; Thu, 10 Sep 2015 07:09:41 -0400 Received: from mout.gmx.net ([212.227.15.15]:57098) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZzjX-0005aa-6j for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 07:09:40 -0400 Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lk7fW-1Z3h7Y0f7q-00cCVW; Thu, 10 Sep 2015 13:09:38 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> Date: Thu, 10 Sep 2015 13:09:36 +0200 In-Reply-To: <83h9n35rgy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 09 Sep 2015 22:21:17 +0300") Message-ID: <87si6mttsf.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:S9Ti0eO13iL7yIsfyaK4cjdA8+a6UtE6+UG4GSnXECp4Ve9cmQc 9Zv/P7Vk9qvds4P0MAmcE42ty6WWUphHm1ezR4GcEXTYxxegfxi3a6xjddWScxxy8K/A8TW XsorTg0GPWrFhilrSOcgsvF8z7nlNhyBzTBNuByth2u9vzeNRaHmMthuvUum5eTROaCgsrd ctAJBrb1J5rfHJhKoFnow== X-UI-Out-Filterresults: notjunk:1;V01:K0:fcWRnUl8Zn0=:TTNjpCKB2joiKXQTj/1YT4 sG7bqmqpEKPUXAOQZB7fjdzYUJ3dR7DVjLk+wYpvHc++hXzcggk68YFfcWBKBgLcJ5NUQ0UAk ZsEAhtOGdqpyGEFP6Ov99BJJwVSVdGHJhdBhthUcDJ31A2xMMeQJb9jzPckQG1jNcCz3K8/CY Y+C2r1XW1HSdckAqWythQ+5Z2yuQxgdprrSwaNnkfHnsLkKWtm2FKAJlVTJfyWqW6XMP5gsJC JG9OaoJeH2+D1ZmYdVIfhCWnsYz5WXtrz3+O7QdjPNCIplGlNmR53aWHm0zIShuFvRiYYg3SW YlYdZXrKu/D79OErcOqX/IdbZ3CZZBliHnEufKIHl7iXA2JFiK1MnF9lBMcVg6xiaus/DX6qW +72JiPMecrj72LZwZx5Utn9Az2iph7M97KDSGY/C2wd4dggtV17Fgik+GsM8nJt3AdBAUnlHm zS6DQGrvpw1ngmtT34JhvrhAmsfNTkyFXGY64VTnAVke18OEok4CLXt2IQayR7JD6IEqgB3hG CYqtzauT7F/swXyUws9WdvH9vONTl8lXLd818IN5O71ocsenDI3eiE0qxi8BfN6Jwu2WOEhtH v2wxuDXUAyRgvfI8b5GASN3G9KVZYiJzxDFDrFaj5rBkYRedL4FSMEMHqIC3D1nCXvQlXV24B uWpbT3Gak01YSKclNOA2GQOo9IGpuqpbTX/ajLV14cuAERQOSwa69Gw9ph917WKikgm/4Qz2J 8yw+V++J8gwJ5N8BRhyNe5NNIZUUkeA7qNX7uw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: >> # mv /tmp/xxx ~/tmp/ > > This doesn't work at all on w32 (I used d:/usr/eli/data instead of > ~/tmp), it reports removal and addition (and also a bogus 2nd > removal): > > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (100286608 removed "xxx") > file-notify-callback)) > | 2 -> (myhandler2 (100286608 deleted "d:/usr/eli/data/xxx")) > | 2 <- myhandler2: nil > 1 <- file-notify-handle-event: nil > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (100286608 added "xxx") > file-notify-callback)) > | 2 -> (myhandler2 (100286608 created "d:/usr/eli/data/xxx")) > | 2 <- myhandler2: nil > 1 <- file-notify-handle-event: nil > ====================================================================== > 1 -> (file-notify-handle-event (file-notify (100286560 removed "xxx") > file-notify-callback)) > | 2 -> (myhandler1 (100286560 deleted "d:/tmp/xxx")) > | 2 <- myhandler1: nil > 1 <- file-notify-handle-event: nil > > Let me know what I should look into or which additional information I > can give you about this. `file-notify-handle-event' is called directly by the low-level library, w32notify here. It sends the events (file-notify (100286608 removed "xxx")) (file-notify (100286608 added "xxx")) (file-notify (100286560 removed "xxx")) The first two events are raised by the file name handler for d:/usr/eli/data. Maybe "xxx" did exist already in that directory? In this case, it would be OK to remove it first. The last event comes from from file name handler for d:/tmp - this looks OK. Well, the order of the events is not as expected (the third event shall be the first one), but we never gave a promise for a canonical order. I would say, that w32notify does not send the renamed-from and renamed-to events, as expected. Maybe they are sent only in case of renaming a file in the same directory? Say # mv /tmp/xxx /tmp/yyy Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 07:23:56 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 11:23:57 +0000 Received: from localhost ([127.0.0.1]:54557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZzxM-0005w6-AB for submit@debbugs.gnu.org; Thu, 10 Sep 2015 07:23:56 -0400 Received: from mout.gmx.net ([212.227.17.21]:59801) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZzxK-0005vx-5p for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 07:23:54 -0400 Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MMYZG-1ZZSnJ41oU-008L0v; Thu, 10 Sep 2015 13:23:52 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> Date: Thu, 10 Sep 2015 13:23:50 +0200 In-Reply-To: <871te7tk9i.fsf@gnu.org> (Tassilo Horn's message of "Wed, 09 Sep 2015 22:23:05 +0200") Message-ID: <87oahatt4p.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:ERuV3QeeLwVTlnk7uysV7Qb+rC9hA9ut58R4dFXYWU0ykz3M+n1 Ik7f4LLFs7SQOaBq9wWZd8+KB8KokI7giOf6r1+02bePsQZgFisguLwKu1QxQjOPoPnUe8W EGqFRaOJfY/vVQy6eB1k+mWIihBDuxiKna1OWfzCqJOQCU8KA9CwL5yQBQ6x10vTwWpdsvX uaSYNPNX5b5+YhXAyUn1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:gErMbyGeA2g=:wbcStvNTLQ3wsiTf/UE9yp I5FdnA0+aazbAzupFdsXfB8OdrLl1WI8HRcyqii1SjGDnGlUewNgetYufqqGjudlv9r+wktlx eH/4ooku/WrN+GSiFIJ8xdOl5rxUjEjnURQIJDAoNXtNfJvO6ydOOw+3HtfqQ9lEPY/uuUsj3 f/rXjfEtwQACA8HuLEzeeGVFew+kAiLrgZ0J5r+wgQvyK1M68PDjmelSxsAOuDI9uSAxOu0ng QobbR6MUvBJcLA1BfgjdmUpUBjEUkllLy1EJ23sJIZXfnjLneuBmlTY+D8YrpwFsX+cJ0A086 6wzY1fGuYqdgbbza8AZnMZEn0co3UymjPaoIWpmIrxAGdRnC+zaVAUz+ZS3tMwXImnHmKt9PP 1K+cdh7j+FKpu9OIy2rP5nPkdJfsdIG9CY+jsu+vJQp2idsFlaAo9azpHrmiy6m4Rw5zJbKzG m7up0NK8xyZ8itMfoTzyhBZBs1WRHSx6mDbNUuYMMQLNpQw7aqE6ECk41uBJ5Zgl/bcyCwr2K VBmhW19WwVQVOya+CyWXDm1xOVeJuTw6l71YtYQ9OykgzRG/HElEHlE6P5m4+kopqI5zDRYdD tzkWANdn3VvP7udNV9futXnrBf7T+/XXoV70JbHOYd8k3g/Wng0xaKoplq2sxORxr2xNY045U 2bfuWvOIvIpKhsSR5bXTSLBxg8bbI2tyvW1AUrtYMg9bNoqQn8zFE5Lyf4mIcAKwQ0TgJQ0Hs 4pk2viUsr7qlsf2WgAH/SQBpl+bKGybgZ8pPuA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Tassilo Horn writes: Hi Tassilo, > Ok, I gave it a whirl and now the `file-notify--test-event-handler' also > records all events in a new variable `file-notify--test-events' for > later analysis. `file-notify-test02-events' now uses that feature to > check if the received events are the expected ones in the expected > order. > > That already revealed two problems: > > 1. Now `file-notify-test02-events-remote' fails because after every > expected `changed' event an additional `attribute-changed' event is > received. This is wrong because when adding the watch, only > '(change) is given as FLAGS argument, not '(change > attribute-change). I'll contact the Tramp maintainer about :-) > 2. When I change the watch FLAGS to '(change attribute-change), there > are still no attribute-changed events received in the local case. attribute-change happens when you change file permissions, or modification time w/o changing the file contents. Something like --8<---------------cut here---------------start------------->8--- (progn (require 'filenotify) (defalias 'myhandler 'ignore) (file-notify-add-watch "/tmp" '(change attribute-change) 'myhandler) (trace-function 'file-notify-handle-event) (trace-function 'myhandler)) # echo xxx > /tmp/xxx ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (create) "xxx" 0) file-notify-callback)) | 2 -> (myhandler ((1) created "/tmp/xxx")) | 2 <- myhandler: nil 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (modify) "xxx" 0) file-notify-callback)) | 2 -> (myhandler ((1) changed "/tmp/xxx")) | 2 <- myhandler: nil 1 <- file-notify-handle-event: nil # chmod 777 /tmp/xxx ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (attrib) "xxx" 0) file-notify-callback)) | 2 -> (myhandler ((1) attribute-changed "/tmp/xxx")) | 2 <- myhandler: nil 1 <- file-notify-handle-event: nil # touch /tmp/xxx ====================================================================== 1 -> (file-notify-handle-event (file-notify (1 (attrib) "xxx" 0) file-notify-callback)) | 2 -> (myhandler ((1) attribute-changed "/tmp/xxx")) | 2 <- myhandler: nil 1 <- file-notify-handle-event: nil --8<---------------cut here---------------end--------------->8--- > And a question: Will the events read by `file-notify--wait-for-events' > still be processed by the handler function? Yes, they should. > And what's the intention of (file-notify--wait-for-events 5 > file-notify--test-results)? The timeout of 5 is reasonable, but the > UNTIL argument here just defines that it waits until the very first of > possibly up to nine yet missing events is awaited here, or do I get > something wrong? Well, this is an open point here. When waiting for events, you don't know how many events will arrive for a given file operation. See the first command above, "echo", it is good for 2 events. So I've taken this heuristics, that after arrival of the first event the other ones will arrive soon. I simply don't know better ... gfilenotify could profit from the changes-done-hint event, which is exactly this kind of information. But we don't have a similar mechanism for inotify or w32notify, as far as I'm aware. If you know of a better check for "alle events we wait for have arrived" - go on. > Bye, > Tassilo Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 11:31:35 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 15:31:35 +0000 Received: from localhost ([127.0.0.1]:55320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za3p0-0004vR-Rs for submit@debbugs.gnu.org; Thu, 10 Sep 2015 11:31:35 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:39406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za3ox-0004vH-Lz for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 11:31:32 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4BD0820C27 for <21435@debbugs.gnu.org>; Thu, 10 Sep 2015 11:31:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 10 Sep 2015 11:31:31 -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=qPvZm1Jf5HXJ0jYVld+f6aoJK/4=; b=dspDI jY8hkIYtv/3CnwT4m6RxrXHjbR/EsaOl4hUXQI36g5BNUsN4I+IoOFUCp1aMhOxp pPuyqeOVB886CuVmYUPggY/Mli/kdjHEDWehsAXw1ol5NnmNlUjWYlUAyOuxEDWR O3W9lTw7rALhSq86jP7LlYWWqYnXWldHABhrcc= X-Sasl-enc: mhwTcR1nx3ubeuqGjSiPbxjxxvKqfTnrhnsoQ6ci8zom 1441899090 Received: from thinkpad-t440p (unknown [2.160.5.146]) by mail.messagingengine.com (Postfix) with ESMTPA id 2743FC00020; Thu, 10 Sep 2015 11:31:29 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> Date: Thu, 10 Sep 2015 17:31:27 +0200 In-Reply-To: <87oahatt4p.fsf@gmx.de> (Michael Albinus's message of "Thu, 10 Sep 2015 13:23:50 +0200") Message-ID: <87a8sunve8.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Michael Albinus writes: >> That already revealed two problems: >> >> 1. Now `file-notify-test02-events-remote' fails because after every >> expected `changed' event an additional `attribute-changed' event is >> received. This is wrong because when adding the watch, only >> '(change) is given as FLAGS argument, not '(change >> attribute-change). > > I'll contact the Tramp maintainer about :-) Deliver him my best wishes. :-) >> 2. When I change the watch FLAGS to '(change attribute-change), there >> are still no attribute-changed events received in the local case. > > attribute-change happens when you change file permissions, or > modification time w/o changing the file contents. Something like Ah, ok, so when you write to a file you'll only get a `changed' event, and not an additional `attribute-changed' event for the changed modification time. So basically, attribute changes are subsumed by `changed' and `created' events. By the way, I think it could be hard to test `attribute-changed' events because those probably depend on the filesystem and mount options on the machine where the tests are run, e.g., if access time recording is enabled or not. >> And a question: Will the events read by >> `file-notify--wait-for-events' still be processed by the handler >> function? > > Yes, they should. Ok, good. >> And what's the intention of (file-notify--wait-for-events 5 >> file-notify--test-results)? The timeout of 5 is reasonable, but the >> UNTIL argument here just defines that it waits until the very first >> of possibly up to nine yet missing events is awaited here, or do I >> get something wrong? > > Well, this is an open point here. When waiting for events, you don't > know how many events will arrive for a given file operation. See the > first command above, "echo", it is good for 2 events. In the tests we know that our test files do not exist initially, so I expect the first write to a file to result in a `created' followed by an `changed' event. And for other operations I have similar expectations, so in the test02 I know that exactly nine events should be received (unless my expectations are wrong). > If you know of a better check for "alle events we wait for have > arrived" - go on. In the concrete case where I know it should be nine events, I could use (= 9 (length file-notify--test-events)) as the UNTIL argument. I've added a new macro to the tests now which lets you do things this way: --8<---------------cut here---------------start------------->8--- ;; Check creation, change, and deletion. (file-notify--test-with-events 3 3 (lambda (events) (should (equal '(created changed deleted) (mapcar #'cadr events)))) (write-region "any text" nil file-notify--test-tmpfile nil 'no-message) (delete-file file-notify--test-tmpfile)) --8<---------------cut here---------------end--------------->8--- This means we're waiting for 3 events for at most 3 seconds, and then apply the lambda to the received events. The rest is the code which causes the events to be emitted. Another thing: the remote tests, especially the test03-autorevert one, take really, really long (maybe 30 seconds). I saw that this uses some mock TRAMP method which suggests it is a mockup connection which can probably simulate a fast or a slow connection. If so, I'd prefer to have a reasonably fast one so that I don't try to avoid running all tests frequently. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 11:45:37 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 15:45:37 +0000 Received: from localhost ([127.0.0.1]:55332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za42b-0005Fz-26 for submit@debbugs.gnu.org; Thu, 10 Sep 2015 11:45:37 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:55643) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za42Y-0005Fp-KR for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 11:45:35 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUG00900WOF7Z00@mtaout27.012.net.il> for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 18:41:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUG00MJOWXZGYC0@mtaout27.012.net.il>; Thu, 10 Sep 2015 18:41:59 +0300 (IDT) Date: Thu, 10 Sep 2015 18:45:13 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87si6mttsf.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <837fny5ldi.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Thu, 10 Sep 2015 13:09:36 +0200 > > file-notify-handle-event' is called directly by the low-level library, > w32notify here. It sends the events > > (file-notify (100286608 removed "xxx")) > (file-notify (100286608 added "xxx")) > (file-notify (100286560 removed "xxx")) Yes. > The first two events are raised by the file name handler for d:/usr/eli/data. > Maybe "xxx" did exist already in that directory? No, it didn't. I don't know why w32 sends this strange notification, but the fact is it does. (That doesn't happen when moving a directory, btw, only when moving files.) > The last event comes from from file name handler for d:/tmp - this looks > OK. Well, the order of the events is not as expected (the third event > shall be the first one), but we never gave a promise for a canonical order. > > I would say, that w32notify does not send the renamed-from and > renamed-to events, as expected. Maybe they are sent only in case of > renaming a file in the same directory? Yes, that's exactly what happens. Which IMO is entirely reasonable, since each watch watches only a single directory. That inotify has some kind of "global" perspective on such rename events is a bonus, but we cannot expect that. This, of course, breaks the basic assumption of the design intended to provide this feature: > Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've > changed filenotify.el to fire 2 events `renamed' in case the directories > of the source and target are different. This was triggered by a user > report, that he wants to have auto-revert-mode for two different > directories under dired control. So the event is sent for the two > different handlers activated by the respective *-add-watch calls. The design expects 2 'move'/'renamed' events, but that's not guaranteed, and doesn't happen on w32. If we want to conflate 'removed' followed by 'added' into a rename across directories, we will need changes in filenotify.el, and will risk false positives, because it could really be a deletion followed by a creation of a file by the same name. However, if all we want is to make sure the destination directory gets a notification (so it could auto-revert), then this already happens on MS-Windows (see the 'created' event above), and therefore nothing should be done on Windows to support the user request above. Therefore, I submit that a better solution would be to make inotify emulate what w32notify does, i.e. produce a synthetic 'added' event in the destination directory when we get a 'moved-to' event that specifies a destination directory different from the source. Finally, two more comments about this: . I wish such changes were discussed, and the various alternatives examined, before the code is changed . I'm not sure this kind of non-trivial logic is something that belongs to filenotify.el; it could well have a better place in auto-revert.el instead, as that is the level where the logic is needed and understood, or even in the Dired-specific function that auto-reverts a directory From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 13:37:35 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 17:37:36 +0000 Received: from localhost ([127.0.0.1]:55521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5mx-0002ki-6Z for submit@debbugs.gnu.org; Thu, 10 Sep 2015 13:37:35 -0400 Received: from mout.gmx.net ([212.227.17.21]:49784) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5mu-0002kZ-P8 for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 13:37:33 -0400 Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUUWN-1ZA0412eBf-00RJhX; Thu, 10 Sep 2015 19:37:30 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> <837fny5ldi.fsf@gnu.org> Date: Thu, 10 Sep 2015 19:37:26 +0200 In-Reply-To: <837fny5ldi.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 18:45:13 +0300") Message-ID: <87wpvyi3ah.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:N0ZHU/vRFrlfRfTMI7/fQOrv/UT5m+ZswITerbCmD5sYn54M0fU YTJqd3f68O0VubmkkXkOZ54wAzqSgvnEcjegB8/pmmjijFisKRt4soiozPV1QcoH5f6utwh Rj3luJu+yVYxQNdwaASULe7elBygSK2Okuaeu1h5Wr4mfZVoKUGwX+BKtref1UblsvYY/8o NNHfdzGmBxBggOUlrmSYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yx4GkmKtCZ8=:pxYM0TAefhqiImCe48TRJ3 TjfoqNlILieJRrcqqekgVMi4F4BKAC1vbdqFPDQqeBOpAn2xVZNCxvRDARToXGN/QcYDSxhZd AxSBIJvzevcp6GvDLxffCmojWfs2r5PsDVv4pSApDBhKlJZ17mI+jIWn4cxMOq4LsbzFBuuST 0AaOKphQ2Fyy4B+6F1El2Xpc43CD5QM9+3RQJ639Ct9nNbMkmFUBvxaaNlI3NohAgrZd03AWz zPjKwZMc1EbChQc5SJvBjdktj2cPEXO62DRZgfJxwKeBrUuDkxUXatlY9KaUTnFl5wuHQk9wQ c90s5jkZAmm5zzSvRdwi/oE0Zs1T28+XWMmYEgM3MxsJ9jOsx0ykhwbnm4aEoHcYSU+ZkKu4n nnJ3hoKjzKn26yG7UeS75ZkhPBmjvZI1N9cvk6onbj+VQEoKd+Zhw/zIbYtwy0+bRp41s9GP0 VzfbBF0xIuscGgQwM+7TfIofagotQwZW0NUt2sYuwmJgUPfxZ61e3TAznxf5ib9tvX1myzeCc ErkoowDXfgdqlt9ogOocb+X7cHIgMuYWXaXcDqUOzCuBPEWJY3Rq5+3sQTysYNB76THHFlLXt 0wkGposCd/VJr7lLOY0WoKsfAhecNSjrYSGBG/hkEXb0MmXHDyhok3vABG1nnVhYXJ6sScyUQ fsGP20XoByz+eqAEhRoWeqe0GDKwqxVPgCWaE2vOM1IXAWn7L9pkHrchKwcKugRAPL8lOysHJ FroYwZKlmSRpWTsd2zcm1QITcveEDW+xKxYSUg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: Hi Eli, >> (file-notify (100286608 removed "xxx")) >> (file-notify (100286608 added "xxx")) >> (file-notify (100286560 removed "xxx")) >> >> The first two events are raised by the file name handler for d:/usr/eli/data. >> Maybe "xxx" did exist already in that directory? > > No, it didn't. I don't know why w32 sends this strange notification, > but the fact is it does. (That doesn't happen when moving a > directory, btw, only when moving files.) Hmm, maybe a bug in the MS Windows library?. However, likely we have no practical problem. The first `removed' event reports the removal of a non-existing file. Nothing a handler shall be concerned about (except the test case Tassilo writes for this ...) >> I would say, that w32notify does not send the renamed-from and >> renamed-to events, as expected. Maybe they are sent only in case of >> renaming a file in the same directory? > > Yes, that's exactly what happens. Which IMO is entirely reasonable, > since each watch watches only a single directory. That inotify has > some kind of "global" perspective on such rename events is a bonus, > but we cannot expect that. Of course. inotify does this by adding an additional cookie to the `moved-from' and `moved-to' events. A pair of such events with the same cookie belongs together. See the example I have shown: 1 -> (file-notify-handle-event (file-notify (1 (moved-from) "xxx" 49278) file-notify-callback)) 1 -> (file-notify-handle-event (file-notify (2 (moved-to) "xxx" 49278) file-notify-callback)) > This, of course, breaks the basic assumption of the design intended to > provide this feature: > >> Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've >> changed filenotify.el to fire 2 events `renamed' in case the directories >> of the source and target are different. This was triggered by a user >> report, that he wants to have auto-revert-mode for two different >> directories under dired control. So the event is sent for the two >> different handlers activated by the respective *-add-watch calls. > > The design expects 2 'move'/'renamed' events, but that's not > guaranteed, and doesn't happen on w32. There's no guarantee. We must say that there will be `renamed' events only when possible. And if not, one must expect two events `deleted' and `created', handled by the respective handler. > If we want to conflate 'removed' followed by 'added' into a rename > across directories, we will need changes in filenotify.el, and will > risk false positives, because it could really be a deletion followed > by a creation of a file by the same name. We will conflate them only when possible. inotify helps us by setting a proper cookie. If w32notify cannot provide this, then we will deliver `deleted' and `created'. > However, if all we want is to make sure the destination directory gets > a notification (so it could auto-revert), then this already happens on > MS-Windows (see the 'created' event above), and therefore nothing > should be done on Windows to support the user request above. It's not only the destination directory, it's also the source directory which matters. Remember the initial use case, two dired buffers under `auto-revert-mode' control. The moved file must appear in the destination dired buffer, and it must disappear in the source dired buffer. > Therefore, I submit that a better solution would be to make inotify > emulate what w32notify does, i.e. produce a synthetic 'added' event in > the destination directory when we get a 'moved-to' event that > specifies a destination directory different from the source. Not necessary I believe. Due to inotify cookie mechanism, it will work robustly. And don't forget gfilenotify, which sends a `rename' event already on low-level. > Finally, two more comments about this: > . I wish such changes were discussed, and the various alternatives > examined, before the code is changed You are right, as always. I didn't expect that there would be such diasagreement. OTOH, I have encouraged Tassilo to improve file-notify-tests.el just in order to have a common base of understanding. The tested (and suceeded) behaviour will be what low-level libraries and filenotify.el have agreed. > . I'm not sure this kind of non-trivial logic is something that > belongs to filenotify.el; it could well have a better place in > auto-revert.el instead, as that is the level where the logic is > needed and understood, or even in the Dired-specific function that > auto-reverts a directory If we only deliver `removed' and `created' events, none of those libraries would have a chance to pair them to a rename action. Essential information, like inotify cookies, will be lost. And yes, this information will be needed. Recently, I saw a discussion on sx, whether Emacs' `auto.revert-mode' could also support file renaming. That is, when a buffer is associated by a file, and that file is renamed outside Emacs, Emacs shall rename `buffer-name' and `buffer-file-name', and then revert. Nice idea ... Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 13:50:27 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 17:50:27 +0000 Received: from localhost ([127.0.0.1]:55536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5zO-00033x-IP for submit@debbugs.gnu.org; Thu, 10 Sep 2015 13:50:26 -0400 Received: from mout.gmx.net ([212.227.15.19]:60911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5zM-00033p-1Y for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 13:50:24 -0400 Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2ts6-1YkkBd0SDm-00sdai; Thu, 10 Sep 2015 19:50:23 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> Date: Thu, 10 Sep 2015 19:50:21 +0200 In-Reply-To: <87a8sunve8.fsf@gnu.org> (Tassilo Horn's message of "Thu, 10 Sep 2015 17:31:27 +0200") Message-ID: <87si6mi2oy.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:HljY69OQfK85fc7A7S4D94MNN/ZsyhblX3G2jeBeX/nMV37S7UP cxIzK2BdOKDbLRGOQXdhqUnwm65tqvZ+NRns2Dgp4z0y2guWcoSswELTvEkQ4Q5km3GZIGh DqO2GNhTe5nz1wQNays1ZA47vuDzIS/xgvlu3x5QKa3fGxvb4dPAiZGrAvsLPrGBxjbZc/T MSBjjMAklpFjmYWQSQiPA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ohv7RaKklKk=:CeJGm7exR0H0wWu+g4PtCD LKPmCufmpBNQ3pSLv5CZy6jfX5LV10rKeQ7tGQdrt1GytrZll5akQgc2IaSSUJ/UcRSpy2Mwp nvmisqAckzBX7HVBuDVQvgQgc1F0GbOx+lY3WIUw5P/6h4Bn5mCXe+4pX9dab8k5RL4c5ZugZ 6qksuUbXNKapfouU+H36Qt6z63hywB1Gsh2ID1/U04fPmSDLPyzAD+x/Dx89U35HACAEqIS/b Y9SJIPXuSVjOL2j6ms9P2hV0OjIboYYfkGS6EHKPDsnwHZZ+mUOV6QrljZ944r2v7mYiryP0D 5pRaCyqLRsSPo3zd31LRGrLf7kuxJ78TsVwIP1y/cy30z9M2a1fJ6aAhmf3pOTZxy+g9Yshlw GpAJf0ATFkosiRXEHV+ZF7NU4h2Ee1nnJrrOJktOOXvqwmrilZnnb8d9wz6aHZ+Q4ppGq4srZ zWozyW1wGHSihRRNsLofe0nhnTrzWI/Ag15Ipuum/2a31HPzHDh7W+mFQINGXSCshpKcdxaSp 5IQHCHxuj6I7jtLi4KyvacG/S0PGDGIi8wDaNPADoXVyDmrhzJLtnXiLvHnwmpGtPotYKngrs ofscl/0zqP6h8ZhnLFkxCG9g1zIBrtZzX22nbdFUNSDLWjfsho+DthXbmMncGmrKyggcU0a9x aD0eq7K6zraOEaRc69vGC74qhhw1/YjpRglqCNSnAKKqkTrxA95mgfa/AW5DUpY/zBetpiUFt WqQfqMOajj2/WAImRLIQGj6dtDL2nuinf67bCw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Tassilo Horn writes: >>> 1. Now `file-notify-test02-events-remote' fails because after every >>> expected `changed' event an additional `attribute-changed' event is >>> received. This is wrong because when adding the watch, only >>> '(change) is given as FLAGS argument, not '(change >>> attribute-change). >> >> I'll contact the Tramp maintainer about :-) > > Deliver him my best wishes. :-) Done. He's working on the problem. > Ah, ok, so when you write to a file you'll only get a `changed' event, > and not an additional `attribute-changed' event for the changed > modification time. So basically, attribute changes are subsumed by > `changed' and `created' events. > > By the way, I think it could be hard to test `attribute-changed' events > because those probably depend on the filesystem and mount options on the > machine where the tests are run, e.g., if access time recording is > enabled or not. Yes. And I also expect here the most notable differences between the native libraries. Not checked yet, 'tho. > I've added a new macro to the tests now which lets you do things this > way: > > ;; Check creation, change, and deletion. > (file-notify--test-with-events > 3 3 (lambda (events) > (should (equal '(created changed deleted) > (mapcar #'cadr events)))) > (write-region > "any text" nil file-notify--test-tmpfile nil 'no-message) > (delete-file file-notify--test-tmpfile)) > > This means we're waiting for 3 events for at most 3 seconds, and then > apply the lambda to the received events. The rest is the code which > causes the events to be emitted. That's good, yes. Please add a docstring to that macro (boring, I know, but it will help other people like Eli and me). One point: you don't call any longer `read-event'. I believe it still makes sense; IIRC I did it because sometimes you must trigger Emacs to check all its file descriptors for new events. > Another thing: the remote tests, especially the test03-autorevert one, > take really, really long (maybe 30 seconds). I saw that this uses some > mock TRAMP method which suggests it is a mockup connection which can > probably simulate a fast or a slow connection. If so, I'd prefer to > have a reasonably fast one so that I don't try to avoid running all > tests frequently. Well, the mockup method is a silly one and it even doesn't require a remote connection, so it shall be faster than any other Tramp method. And I do not experience serious delays when testing. You could alway skip all the remote tests. Call # env REMOTE_TEMPORARY_FILE_DIRECTORY=/dev/null make -C test/automated file-notify-tests > Bye, > Tassilo Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 14:03:19 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:03:19 +0000 Received: from localhost ([127.0.0.1]:55549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Br-0003Nk-01 for submit@debbugs.gnu.org; Thu, 10 Sep 2015 14:03:19 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:45791) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Bo-0003Na-8K for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 14:03:17 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NUH009003JHO800@mtaout26.012.net.il> for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 21:05:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUH008PR3LBYV00@mtaout26.012.net.il>; Thu, 10 Sep 2015 21:05:35 +0300 (IDT) Date: Thu, 10 Sep 2015 21:03:05 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87wpvyi3ah.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83wpvy40fa.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> <837fny5ldi.fsf@gnu.org> <87wpvyi3ah.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Thu, 10 Sep 2015 19:37:26 +0200 > > > However, if all we want is to make sure the destination directory gets > > a notification (so it could auto-revert), then this already happens on > > MS-Windows (see the 'created' event above), and therefore nothing > > should be done on Windows to support the user request above. > > It's not only the destination directory, it's also the source directory > which matters. Remember the initial use case, two dired buffers under > `auto-revert-mode' control. The moved file must appear in the > destination dired buffer, and it must disappear in the source dired buffer. Yes, and both events happen in this scenario, on Windows as well as on GNU/Linux. So the fact that the move is not reported as a move will not cause any problems in this use case. > > Therefore, I submit that a better solution would be to make inotify > > emulate what w32notify does, i.e. produce a synthetic 'added' event in > > the destination directory when we get a 'moved-to' event that > > specifies a destination directory different from the source. > > Not necessary I believe. Due to inotify cookie mechanism, it will work > robustly. And don't forget gfilenotify, which sends a `rename' event > already on low-level. I'm guessing that gfilenotify only does that when its back-end is inotify. E.g., I doubt that it could do this when it uses its fallback polling method. > > . I'm not sure this kind of non-trivial logic is something that > > belongs to filenotify.el; it could well have a better place in > > auto-revert.el instead, as that is the level where the logic is > > needed and understood, or even in the Dired-specific function that > > auto-reverts a directory > > If we only deliver `removed' and `created' events, none of those > libraries would have a chance to pair them to a rename action. They shouldn't rely on that in the first place, since this is unreliable, as we just saw. And in the case in point, it's unnecessary anyway, since all you need is to have events in both source and destination. These events do not have to be 'rename' events. > Essential information, like inotify cookies, will be lost. On filenotify.el level, yes. I thought filenotify.el exists to try to present a more or less unified interface independent of the back-end. If such differences in back-end behavior are seen by clients of filenotify.el, then how is it different from invoking the back-end directly? > And yes, this information will be needed. Recently, I saw a discussion > on sx, whether Emacs' `auto.revert-mode' could also support file > renaming. That is, when a buffer is associated by a file, and that file > is renamed outside Emacs, Emacs shall rename `buffer-name' and > `buffer-file-name', and then revert. Nice idea ... The problem we are discussing does not exist in this scenario, AFAIU. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 14:21:00 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:21:00 +0000 Received: from localhost ([127.0.0.1]:55560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Sx-0003p6-K8 for submit@debbugs.gnu.org; Thu, 10 Sep 2015 14:21:00 -0400 Received: from mout.gmx.net ([212.227.15.18]:57739) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Sw-0003oy-49 for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 14:20:58 -0400 Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M54L0-1YiYuX0fXy-00zFJd; Thu, 10 Sep 2015 20:20:55 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> <837fny5ldi.fsf@gnu.org> <87wpvyi3ah.fsf@gmx.de> <83wpvy40fa.fsf@gnu.org> Date: Thu, 10 Sep 2015 20:20:54 +0200 In-Reply-To: <83wpvy40fa.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 21:03:05 +0300") Message-ID: <87twr29lvd.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:1A5M+LSyADHnYHmWUok3oJvmIM/se9UmjqthckvPcpYoGGEJYJu Dsdb6nBDBvaudo9ajlYdEA4jvKlbKFQ4v8ImhR4o8NFVi0i4Siv0CE5GPq+4e7AZA5+db/Q Oc5qzXRXkDPY2DMT7qv8hbmi/xXeB3I7CQ1tRJ53QBRFZp4AtghsDFDKoHD+55HdqD0vhhL gQjlL5RfTKTfrnJsLlz5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:1oEeWHXtirs=:1jQCU0UBiAT99YXEkv069X bpTJGeFWA1MfUq8gB3Pjnxms6v9Nmu7hSulKQqE+blu9fzWoTSkhVb1mgE3W4eNPrWuk3Wdzg CBO0SRMfxzRjnGB3fnRLN14TtngV4QuNzpP6mOUW9stl+rHxu1voNHacYD2nnnQSVlHHlKWcJ Z4b7tANaW3KwmI8SywoaEGZ0Oc9B1d1tMa4tAwEY2rBAl6orKXHPYFp9z7BpyAvyfnbwaLRYc qHqQsu4bMgjZ91ZrFg9gnXLL32Vz+QiAhv1WsGlYqN8Z2TfkpukcALSxn+B9sL2SmXAAd2x6V soAWbLIdwpjSQVf2yQM7dY9fbqzLFQ9rqhCvT+3eYXtW8FlzfZEjls5lXjacofUWVDX8EbRMI GofeC1NxJGwJQ0UtVDv9UNgyEvkc43mONwrlcpizvOMKoxlhns+Ilp0smSfdUzLrT9SMuubRQ Sf6XWHq7syAwQObm8+leMfY7yoejh+vgdGGQIBghXpYh0mAauQoZ08Om384eEpI14wZr7AgP8 C9BVcOsKunh0In7O0Y6Ly9hiTYeHcf11/rd5dB4W4bk4EfVAKiguZpf63RtttfsG1gdTo1uOn FVcSJ+Tp43QWXyEGGYVxgyz5Zg+C7BOUbHLVQiJg+4DXH4lS92/8b+rsDakfZTnLz0khQPQhW 4pWmBraUc3lu29epmApFNRJ72kvPNy0Nsis2vRSmbSWg3SrMtjeGa3P+tE0PHVMIdroJ/+1/f 6uR08GuIL4XCIIUU873SWpco60nQucaEtzp0/A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: >> > However, if all we want is to make sure the destination directory gets >> > a notification (so it could auto-revert), then this already happens on >> > MS-Windows (see the 'created' event above), and therefore nothing >> > should be done on Windows to support the user request above. >> >> It's not only the destination directory, it's also the source directory >> which matters. Remember the initial use case, two dired buffers under >> `auto-revert-mode' control. The moved file must appear in the >> destination dired buffer, and it must disappear in the source dired buffer. > > Yes, and both events happen in this scenario, on Windows as well as on > GNU/Linux. So the fact that the move is not reported as a move will > not cause any problems in this use case. For that dired case, yes. I was answering to your statement "if all we want is to make sure the destination directory ..." >> Not necessary I believe. Due to inotify cookie mechanism, it will work >> robustly. And don't forget gfilenotify, which sends a `rename' event >> already on low-level. > > I'm guessing that gfilenotify only does that when its back-end is > inotify. E.g., I doubt that it could do this when it uses its > fallback polling method. Maybe, I haven't checked. But the point is that we send a `renamed' event only we can trust there is a file move. Otherwise, we send `deleted' and `created'. >> > . I'm not sure this kind of non-trivial logic is something that >> > belongs to filenotify.el; it could well have a better place in >> > auto-revert.el instead, as that is the level where the logic is >> > needed and understood, or even in the Dired-specific function that >> > auto-reverts a directory >> >> If we only deliver `removed' and `created' events, none of those >> libraries would have a chance to pair them to a rename action. > > They shouldn't rely on that in the first place, since this is > unreliable, as we just saw. Nope. When filenotify.el sends a `renamed' event, it must be reliable. Because we got it from gfilenotify, because we could pair the events via inotify cookies, whatever. When it is not reliable, we send `deleted' and `created', which has less semantics than `renamed'. > And in the case in point, it's unnecessary anyway, since all you need > is to have events in both source and destination. These events do not > have to be 'rename' events. In the use cases we know today, you are right. But there might be other use cases where it matters. And again, `renamed' events provide more information than single `deleted' and `created' events. >> Essential information, like inotify cookies, will be lost. > > On filenotify.el level, yes. I thought filenotify.el exists to try to > present a more or less unified interface independent of the back-end. > If such differences in back-end behavior are seen by clients of > filenotify.el, then how is it different from invoking the back-end > directly? There is already a difference: native gfilenotify gives us a `rename' event. Shall we convert it to `deleted' and `created'? This would reduce the information. >> And yes, this information will be needed. Recently, I saw a discussion >> on sx, whether Emacs' `auto.revert-mode' could also support file >> renaming. That is, when a buffer is associated by a file, and that file >> is renamed outside Emacs, Emacs shall rename `buffer-name' and >> `buffer-file-name', and then revert. Nice idea ... > > The problem we are discussing does not exist in this scenario, AFAIU. That scenario would work only if there is a `renamed' event. How else autorevert could decide, that a file has been moved? What is its new name? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 14:55:52 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:55:52 +0000 Received: from localhost ([127.0.0.1]:55588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za70h-0004eZ-Ty for submit@debbugs.gnu.org; Thu, 10 Sep 2015 14:55:52 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:48675) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za70e-0004eP-Oh for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 14:55:50 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NUH00M005PR2600@mtaout25.012.net.il> for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 21:52:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUH00BKB5RL97A0@mtaout25.012.net.il>; Thu, 10 Sep 2015 21:52:34 +0300 (IDT) Date: Thu, 10 Sep 2015 21:55:38 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87twr29lvd.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83si6m3xzp.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> <837fny5ldi.fsf@gnu.org> <87wpvyi3ah.fsf@gmx.de> <83wpvy40fa.fsf@gnu.org> <87twr29lvd.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Thu, 10 Sep 2015 20:20:54 +0200 > > >> > . I'm not sure this kind of non-trivial logic is something that > >> > belongs to filenotify.el; it could well have a better place in > >> > auto-revert.el instead, as that is the level where the logic is > >> > needed and understood, or even in the Dired-specific function that > >> > auto-reverts a directory > >> > >> If we only deliver `removed' and `created' events, none of those > >> libraries would have a chance to pair them to a rename action. > > > > They shouldn't rely on that in the first place, since this is > > unreliable, as we just saw. > > Nope. When filenotify.el sends a `renamed' event, it must be > reliable. That's not what I meant. What I meant was that applications cannot rely on getting a 'renamed' event when files are moved between directories, they should be prepared to deal with 'deleted' and 'created' anyway. > > And in the case in point, it's unnecessary anyway, since all you need > > is to have events in both source and destination. These events do not > > have to be 'rename' events. > > In the use cases we know today, you are right. But there might be other > use cases where it matters. And again, `renamed' events provide more > information than single `deleted' and `created' events. Those use cases will have to handle 'deleted' and 'created', if they want to work on all supported platforms. By sending sometimes 'renamed' and sometimes 'deleted' followed by 'created', we ask the users to do more work, and gratuitously expose them to platform differences that filenotify.el was supposed to conceal. > >> Essential information, like inotify cookies, will be lost. > > > > On filenotify.el level, yes. I thought filenotify.el exists to try to > > present a more or less unified interface independent of the back-end. > > If such differences in back-end behavior are seen by clients of > > filenotify.el, then how is it different from invoking the back-end > > directly? > > There is already a difference: native gfilenotify gives us a `rename' > event. Shall we convert it to `deleted' and `created'? Yes. > This would reduce the information. Applications that don't want to lose that information can always call back-ends directly. By using filenotify.el, they agree to losing some information, and in return gain uniformity and less coding. > >> And yes, this information will be needed. Recently, I saw a discussion > >> on sx, whether Emacs' `auto.revert-mode' could also support file > >> renaming. That is, when a buffer is associated by a file, and that file > >> is renamed outside Emacs, Emacs shall rename `buffer-name' and > >> `buffer-file-name', and then revert. Nice idea ... > > > > The problem we are discussing does not exist in this scenario, AFAIU. > > That scenario would work only if there is a `renamed' event. How else > autorevert could decide, that a file has been moved? What is its new name? In the same directory, there _is_ a 'renamed' event. We are discussing a situation when a file was moved to another directory, which is not what this scenario is about. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 15:22:08 2015 Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 19:22:08 +0000 Received: from localhost ([127.0.0.1]:55612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za7Q8-0005KQ-7U for submit@debbugs.gnu.org; Thu, 10 Sep 2015 15:22:08 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:50201) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za7Q6-0005KH-4U for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 15:22:06 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CE896203DD for <21435@debbugs.gnu.org>; Thu, 10 Sep 2015 15:22:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 10 Sep 2015 15:22:05 -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=RdS+PhnGyEJODHE3JP8u6m6LGm0=; b=WWEwn 4hCHnWYo0uGoBe+L6KRmInnyMj8WNEHoDrKpJ0bkWYqdBb1+ptPaItUnc3GKu3Nt c6SwtzzBwD/4UFGrS0xjbFpLkQt2/kumS2aXWQODvSNfWxcrdolG9JyLIhbfX8nz pJTiWkU1aPpgmYJRQ2TUpwiwRXAGfrT+hRHjJs= X-Sasl-enc: yN3BYjLwAgYoUyu+s3sfNQLlmmxyrVOHCaPPKkbTM+dr 1441912925 Received: from thinkpad-t440p (unknown [2.160.5.146]) by mail.messagingengine.com (Postfix) with ESMTPA id 9A166C00285; Thu, 10 Sep 2015 15:22:04 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> Date: Thu, 10 Sep 2015 21:22:02 +0200 In-Reply-To: <87si6mi2oy.fsf@gmx.de> (Michael Albinus's message of "Thu, 10 Sep 2015 19:50:21 +0200") Message-ID: <87613inkpx.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Michael Albinus writes: >> I've added a new macro to the tests now which lets you do things this >> way: >> >> ;; Check creation, change, and deletion. >> (file-notify--test-with-events >> 3 3 (lambda (events) >> (should (equal '(created changed deleted) >> (mapcar #'cadr events)))) >> (write-region >> "any text" nil file-notify--test-tmpfile nil 'no-message) >> (delete-file file-notify--test-tmpfile)) >> >> This means we're waiting for 3 events for at most 3 seconds, and then >> apply the lambda to the received events. The rest is the code which >> causes the events to be emitted. > > That's good, yes. Please add a docstring to that macro (boring, I > know, but it will help other people like Eli and me). Done. > One point: you don't call any longer `read-event'. I believe it still > makes sense; IIRC I did it because sometimes you must trigger Emacs to > check all its file descriptors for new events. I still do. That macro uses `file-notify--wait-for-events' to wait until all N events have arrived before calling the ASSERT-FN. >> Another thing: the remote tests, especially the test03-autorevert >> one, take really, really long (maybe 30 seconds). I saw that this >> uses some mock TRAMP method which suggests it is a mockup connection >> which can probably simulate a fast or a slow connection. If so, I'd >> prefer to have a reasonably fast one so that I don't try to avoid >> running all tests frequently. > > Well, the mockup method is a silly one and it even doesn't require a > remote connection, so it shall be faster than any other Tramp method. > And I do not experience serious delays when testing. Hm, then I wonder what causes these extreme delays here. The remote autorevert test really takes at least 20 seconds here. But I have no issues using TRAMP with its ssh method for accessing really remote files... > You could alway skip all the remote tests. As your tester, I obviously want to run all tests. :-) Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 05:45:45 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 09:45:45 +0000 Received: from localhost ([127.0.0.1]:56167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaKts-0000sm-O9 for submit@debbugs.gnu.org; Fri, 11 Sep 2015 05:45:45 -0400 Received: from mout.gmx.net ([212.227.15.18]:60098) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaKtp-0000sc-EI for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 05:45:42 -0400 Received: from detlef.gmx.de ([79.195.7.210]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lymoh-1YX58t00Sl-0165g7; Fri, 11 Sep 2015 11:45:40 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> Date: Fri, 11 Sep 2015 11:45:38 +0200 In-Reply-To: <87si6mi2oy.fsf@gmx.de> (Michael Albinus's message of "Thu, 10 Sep 2015 19:50:21 +0200") Message-ID: <87vbbhl265.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:knQ4XX5LU4jlkVBc/SFl4HvjQEVjsLUuIAk9+5tmSZvd2Q808fi aFuIWlELKcQZkk+cAnmj5CfcTBipT1CQLciJIODBOGcodH7iueDX4LGhd+wlaITuyfPyhKf EY5RIrNaVu2aeFTnU7FWHx5ptU2gpQUfoXIduOEi8JptInBapNWC1O90wRywKpoShs3arYS b5VTJ4/s9rviWreMUmUXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:DaGgkqbWr2c=:T6CKdgri968W4/jtYEZW3h NYXdxC2y1NSFcG56Cp/5AH6BkNY/jct95MlOt9qeoNvKB3J3PtBR8ZF1axYHjt173qXjzeixn 4nnLcQqicSJcvK4JWrh/2y6PPxJcCsbyHzI1mSVGncFshyu433iFSzb4XVEDqLlRQ5AKKCSLv DtzEGoHo10N027GpOdhvo0sjvvkZypgLXRecFILomR1EgpaB/Y1lXm2Q9WeiUXNQShGkPJtDB 3NPo+Kj+6TGH9WxNdG03qr4xb0FWvGvZ0f+pQv1Q2steKcfVjbaRlt0FeNqw1IfsW3gQ+llrv nMXohXOwEoX5lQmWlq7YZlhYZ5H2dqFXt/1WtRwq+UFOi4GetNJKPWi5iPLjImpz/x50scsXt G+jV5djPhRlm2Rpc4n35mA1Mhi9PS/Oz+qT5RW38FztJ7dpcUMHgfyoTfiG7Q/x6mRIYZzKJw 9GBLfyLh7J5Fw6fXqXQ9p80MLC6qVjEVftneAKWmqvT3A+u7qORjPbKkXuouHrLqQx0SrLeV4 sx39cOGt4MVGrV0UN2obB4ISRXEz9P6OBOp7yhTQfRtRfg4h9Gr3c4avKIBoiNVDxUtf6uo4A xJTRPSWzZUOXbNrOmj3Qqq2WoUTruquE1iDS3R/LPBoJ7+KBx6G+ptnTAUTuZSnCnK/zpkUly MXtjy+3fvBN/W6TIOtXpwJisHPb4q01LdValH3/AuW6EWKnVNMRGDRZpa8dskcq+7FYqeNKhL cjhoV/umtW857YacyqwtIvATja1udiy630/uBQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Michael Albinus writes: > Tassilo Horn writes: > >>>> 1. Now `file-notify-test02-events-remote' fails because after every >>>> expected `changed' event an additional `attribute-changed' event is >>>> received. This is wrong because when adding the watch, only >>>> '(change) is given as FLAGS argument, not '(change >>>> attribute-change). >>> >>> I'll contact the Tramp maintainer about :-) >> >> Deliver him my best wishes. :-) > > Done. He's working on the problem. Should be fixed now. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 05:53:52 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 09:53:52 +0000 Received: from localhost ([127.0.0.1]:56173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaL1j-000143-Uk for submit@debbugs.gnu.org; Fri, 11 Sep 2015 05:53:52 -0400 Received: from mout.gmx.net ([212.227.15.18]:64694) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaL1i-00013w-8y for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 05:53:50 -0400 Received: from detlef.gmx.de ([79.195.7.210]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MAyZg-1ZSbFY158e-009z7L; Fri, 11 Sep 2015 11:53:48 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> <87613inkpx.fsf@gnu.org> Date: Fri, 11 Sep 2015 11:53:47 +0200 In-Reply-To: <87613inkpx.fsf@gnu.org> (Tassilo Horn's message of "Thu, 10 Sep 2015 21:22:02 +0200") Message-ID: <87r3m5l1sk.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:Jjiu/OStVUp04bIaNdpJtLvBGhPk3w6W///3y4VmDTikCh2Be7g eevlCvLobipav/nATp02TNEqu2BMMG2FG29hDmcBu5joZNDiFCeeWV/5OCo4d5T7nzo1l8E D3v4ULmsN2oUOR+Lw3XWxZvJwPy1vEXtDr28IWjj7gJpqEQoTSmFpy4Y8nPkxEjRpuZ6/Cr Uu79CuGYEUeXO5rnVKUvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:rqog/NOolXE=:eR2jEyPlceMVjCwueTkm79 KxjJ1Gtdq4sjT6Lr39S/S1nB9TI7e72waU/nVhrNUZkwu5H/TEjLWqeWTisjFSIglK3l8GxPz gEJBVm+cNRw5bJg713ZTNvjW6R6DqIHn+eCrzHISva6jc/XfHus3BcaaQbpXQdzbcH/BBpLTl OqcuC7YZMWGZJuGQZB5bsJfqcA3z/kF4dgTwWnKHMNf/Nchx8hwYCVHBNIn6vdw2OtCUcchzI k1eZddurrxpqqnotykPRoVyuigzEMgFw32BdTErCYUV1L5V4wGV5VjZMsVZUq5rXrthNcxujW zb+NgVjIV8XY8BSg5eR+A4kke1XAI6/r16U2zFbjuOvk3srEbP/n1tfWM0XbqOD57HIqzotWY lnSNpVyZjsAgFLxEY28e6d40A9TAdXM5tGYcEMwqaw6YdtW7e+HujSgxfBBui7tGdR8b1xDxY q0yNP6kmD5RS9ymG4i3lY5cByIcFUQz1z7oYNfFo/Z29/Yi5uOAxnDFmxVG/h82dW9irtYWzY /LH5DH75x0Buh7Ikhoes4NLTcacPJZ6p53dAVlD5cmpaytIkBzv9+sxiNUWjDCgm0SRG2su+1 k+U5THIBVEwpARmxgEFsTAEw0K1Axa5WixMaYFarOyAr99m31F/diJ4sXKvGhTZwkNCZEHfxs y6hSeSg7H7yxYUcXCMjZcd62NRyKhQHv7kr3SxljHzBFkN+1BLc+MF1m/tmkQpSQIQtA3x2Z5 umye427YQBGVRD1uhG6at0sQZQtcz9MYouWbVw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Tassilo Horn writes: >>> I've added a new macro to the tests now which lets you do things this >>> way: >>> >>> ;; Check creation, change, and deletion. >>> (file-notify--test-with-events >>> 3 3 (lambda (events) >>> (should (equal '(created changed deleted) >>> (mapcar #'cadr events)))) >>> (write-region >>> "any text" nil file-notify--test-tmpfile nil 'no-message) >>> (delete-file file-notify--test-tmpfile)) >>> >>> This means we're waiting for 3 events for at most 3 seconds, and then >>> apply the lambda to the received events. The rest is the code which >>> causes the events to be emitted. >> >> That's good, yes. Please add a docstring to that macro (boring, I >> know, but it will help other people like Eli and me). > > Done. Thanks. Another point is whether we always can expect that all native libraries will report exactly the same number of events, and then whether they report them exactly in the same order (you expect '(created changed deleted) here). Let's see how the test cases evolve, maybe we need more tolerant tests. >> One point: you don't call any longer `read-event'. I believe it still >> makes sense; IIRC I did it because sometimes you must trigger Emacs to >> check all its file descriptors for new events. > > I still do. That macro uses `file-notify--wait-for-events' to wait > until all N events have arrived before calling the ASSERT-FN. Yep, I've overseen this. OK. > Hm, then I wonder what causes these extreme delays here. The remote > autorevert test really takes at least 20 seconds here. But I have no > issues using TRAMP with its ssh method for accessing really remote > files... Now I see it also, but only when running in interactive mode. In batch mode, there is no serious delay. Will contact the Tramp maintainer, again. > Bye, > Tassilo Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:11:24 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 12:11:24 +0000 Received: from localhost ([127.0.0.1]:56219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNAq-0005pf-8t for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:11:24 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53829) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNAn-0005pW-PA for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 08:11:22 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id CE238207D8 for <21435@debbugs.gnu.org>; Fri, 11 Sep 2015 08:11:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 11 Sep 2015 08:11:19 -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=nSYyuXVLHRfbvrpdwU3D0VREwvs=; b=EG7Mv RqNOPSyuuLssNDbqD0nAQUnPTYMwpDpSHr7ziCqVMYaxOSzOOi8YGgzdM2r8lFbB uSTFfajc59fsQ73KquhL50gHQf628McNFbLfq6ZwNlCYqpPqjmsWEf6oydwDypye J5taTrO/dhPAGSXVal4n0FXp+7MQoYRngkoVbU= X-Sasl-enc: JXoRLpaZPkHHttXkqYpo+co9MYEha45qVyVexqqf+1wS 1441973479 Received: from thinkpad-t440p (unknown [2.161.110.122]) by mail.messagingengine.com (Postfix) with ESMTPA id E2CEBC00290; Fri, 11 Sep 2015 08:11:18 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> <87vbbhl265.fsf@gmx.de> Date: Fri, 11 Sep 2015 14:11:16 +0200 In-Reply-To: <87vbbhl265.fsf@gmx.de> (Michael Albinus's message of "Fri, 11 Sep 2015 11:45:38 +0200") Message-ID: <87egi59mvv.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Michael Albinus writes: >>>>> 1. Now `file-notify-test02-events-remote' fails because after every >>>>> expected `changed' event an additional `attribute-changed' event is >>>>> received. This is wrong because when adding the watch, only >>>>> '(change) is given as FLAGS argument, not '(change >>>>> attribute-change). >>>> >>>> I'll contact the Tramp maintainer about :-) >>> >>> Deliver him my best wishes. :-) >> >> Done. He's working on the problem. > > Should be fixed now. Yes, it is. Thanks! Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:17:09 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 12:17:09 +0000 Received: from localhost ([127.0.0.1]:56223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNGP-0005y6-4T for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:17:09 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:46489) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNGN-0005xx-35 for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 08:17:07 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D978C20856 for <21435@debbugs.gnu.org>; Fri, 11 Sep 2015 08:17:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 11 Sep 2015 08:17:06 -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=Wh9SMtlUcFDVRsuj5OX0HK8Al/Y=; b=dghn4 IL29pIcyiEtWAwM29Z4I274oc7xoG1GuOI3X+89yfOt3ou4NE7ptuO5q0hoWSBmV uKm0BIf0wgylbXoWSikJ38mJet/hQPRl1/iqtIyHYX/yjlWOYrNriXMFLUn6nmfP 0VOQrzL/nq9f2Ibn8GwtNvFQaJfs3gdyeIlJRo= X-Sasl-enc: +zbQpEMaPcM+k50ftxkQ+ETrEsBi9qnMQZzy2nHy+3ts 1441973826 Received: from thinkpad-t440p (unknown [2.161.110.122]) by mail.messagingengine.com (Postfix) with ESMTPA id D0B27C00293; Fri, 11 Sep 2015 08:17:05 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> <87613inkpx.fsf@gnu.org> <87r3m5l1sk.fsf@gmx.de> Date: Fri, 11 Sep 2015 14:17:03 +0200 In-Reply-To: <87r3m5l1sk.fsf@gmx.de> (Michael Albinus's message of "Fri, 11 Sep 2015 11:53:47 +0200") Message-ID: <87a8st9mm8.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-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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.3 (/) Michael Albinus writes: > Thanks. Another point is whether we always can expect that all native > libraries will report exactly the same number of events, and then > whether they report them exactly in the same order (you expect > '(created changed deleted) here). Let's see how the test cases evolve, > maybe we need more tolerant tests. Yes, I'm quite strict right now and IMHO in the current tests, that's the only sensible order of events. But of course if it turns out that with some notification backend we can't achieve that guarantee, it'll be no problem to relax the assertions a bit. >> Hm, then I wonder what causes these extreme delays here. The remote >> autorevert test really takes at least 20 seconds here. But I have no >> issues using TRAMP with its ssh method for accessing really remote >> files... > > Now I see it also, but only when running in interactive mode. In batch > mode, there is no serious delay. Will contact the Tramp maintainer, again. Yes, you are right. I always executed the test interactively and now tried running them from the command line. Indeed, that's way faster. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:33:19 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 12:33:19 +0000 Received: from localhost ([127.0.0.1]:56237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNW3-0006a0-7T for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:33:19 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:58820) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNW0-0006Zq-KP for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 08:33:17 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NUI00500IKV7D00@a-mtaout20.012.net.il> for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 15:32:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUI004R2IUJLXC0@a-mtaout20.012.net.il>; Fri, 11 Sep 2015 15:32:43 +0300 (IDT) Date: Fri, 11 Sep 2015 15:32:36 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87a8st9mm8.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <834mj13zmj.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> <87613inkpx.fsf@gnu.org> <87r3m5l1sk.fsf@gmx.de> <87a8st9mm8.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, michael.albinus@gmx.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 , 21435@debbugs.gnu.org > Date: Fri, 11 Sep 2015 14:17:03 +0200 > > Michael Albinus writes: > > > Thanks. Another point is whether we always can expect that all native > > libraries will report exactly the same number of events, and then > > whether they report them exactly in the same order (you expect > > '(created changed deleted) here). Let's see how the test cases evolve, > > maybe we need more tolerant tests. > > Yes, I'm quite strict right now and IMHO in the current tests, that's > the only sensible order of events. But of course if it turns out that > with some notification backend we can't achieve that guarantee, it'll be > no problem to relax the assertions a bit. I think if we ever find that the order is not guaranteed, we should sort the events into the "right" order in filenotify.el. Once again, the sole reason for having filenotify.el is to present a unified API to applications, so that they don't need to know anything about the back-ends and their idiosyncrasies. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:51:21 2015 Received: (at 21435) by debbugs.gnu.org; 11 Sep 2015 12:51:21 +0000 Received: from localhost ([127.0.0.1]:56257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNnU-0006zZ-UX for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:51:21 -0400 Received: from mout.gmx.net ([212.227.17.20]:63985) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNnT-0006zR-GH for 21435@debbugs.gnu.org; Fri, 11 Sep 2015 08:51:19 -0400 Received: from detlef.gmx.de ([79.195.7.210]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6874-1YgdYM2iTq-00y6Y4; Fri, 11 Sep 2015 14:51:16 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <8737ynv3ik.fsf@gmx.de> <83h9n35rgy.fsf@gnu.org> <87si6mttsf.fsf@gmx.de> <837fny5ldi.fsf@gnu.org> <87wpvyi3ah.fsf@gmx.de> <83wpvy40fa.fsf@gnu.org> <87twr29lvd.fsf@gmx.de> <83si6m3xzp.fsf@gnu.org> Date: Fri, 11 Sep 2015 14:51:15 +0200 In-Reply-To: <83si6m3xzp.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 21:55:38 +0300") Message-ID: <87lhcdktks.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:GjdtBavYSMM+DicnR/lwdQ9yj6czR3wqmPNYrPixkSrOCo1zCME XtkZZcXUWYvBzWh17JHmrzNAYci1cgR+Rojk51wiUR90/rP7yP3CjKgjYBjrjNa4tOImc9/ 2ZmLjeQFVOW7GQahIx9eAWWidNGPdcUPBVrG9OvbRGd4N3odU80SresMgTSyKy4RmYmaKn3 XUIzHFHEoF9PhJgx8RaXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:91gez2R7/W4=:lZdYXU4pkRpv2m3tbj1vLv LaSmdhYFUjMzP1Gr+mW2DRYvwUvqI1CftsDuywl4m8X5Kekbg0ZrL6cvKtKpReRa7A5DOpFG8 S0e6fo4xUqFz7gq76oO1AfBJTbou7/YX1XTIv7JuNryqN9DpYYqTMU0pTwNHYhg/gxGtQ1gtD xAzYLZc1tNzkJNOBBU9Tl0o7O07ow5fhhvoHW/1rISlVL8Xi3MoKyyJmGSIl9UTSPOEcnL01e kTLcoX8PyZ/T8ygWSgs6P8IWBZfKnlw3D5EHaMBtDPmZ5g2683HiLmN28R3NmpEwf61FHVmSw PypD+fnCB3en29J+DDFdOwMfpOGN6mCeF7h4lGkh+8ofAA3ih+rrLtuGfbp/VQl6SuYxVAzmR N/f6GhebCASA7RIb3aDwsW3d42IovcxjxnSXS7y9rupIdLlH3Gleq1+rc3yXUBiYYStiuy+Ub 7/n0ZjHC5+vB8FpFLKiUbRebanq3SFeMXCHVdy8+E9HGng6ySo6HLhEW9hWJaru3LaCiTO6+8 BTeVOcC/RwoHChxyZEc68kgkZCUAlsO9905Z0Ywardscn8a7pJVgSItw+X1CChlSySd7a1bcr 6kzApD1yXTGt4g7Y8KaTncycapQky5Y/kXgd/9ym+MdtlBfwfwmTS7yy09r55gmBj8Mvxdzx5 CxkA+Rt93tUFEZGwm9HAIBabNXgj90oV8Apgwwe7Ifp7fEGUSiWZcKVT4acTbhKEX7UrzXpH+ GNBL59hv4LpePuAg2rG66RWeE+yBn9P7W4Kf0w== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: >> > They shouldn't rely on that in the first place, since this is >> > unreliable, as we just saw. >> >> Nope. When filenotify.el sends a `renamed' event, it must be >> reliable. > > That's not what I meant. What I meant was that applications cannot > rely on getting a 'renamed' event when files are moved between > directories, they should be prepared to deal with 'deleted' and > 'created' anyway. Ahh, I misunderstood you. And yes, I don't believe it is a burden for applications to react on `renamed', `deleted' and `created'. > Those use cases will have to handle 'deleted' and 'created', if they > want to work on all supported platforms. By sending sometimes > 'renamed' and sometimes 'deleted' followed by 'created', we ask the > users to do more work, and gratuitously expose them to platform > differences that filenotify.el was supposed to conceal. I believe we don't have platform differences. On all supported platforms, we could compose a `renamed' event. gfilenotify sends `rename', inotify sends the `moved-from' / `moved-to' pair, and w32notify sends the `renamed-from' / `renamed-to' pair. None of the platforms guarantees, that a move operation will result in those events, remember the case of moving a file from a local disk to a mounted disk (a share for MS-Windows). Then they send their `deleted' / `created' equivalents. What we do is harmonizing a little bit the different native libraries. We don't do anything else. >> There is already a difference: native gfilenotify gives us a `rename' >> event. Shall we convert it to `deleted' and `created'? > > Yes. Here I disagree. >> This would reduce the information. > > Applications that don't want to lose that information can always call > back-ends directly. By using filenotify.el, they agree to losing some > information, and in return gain uniformity and less coding. See the example above. It would be a horror for them to handle all the different low-level events. filenotify.el would simplify it. And again, I don't believe it is too much work for an application, to handle a `renamed' event, when they are already capable to handle `deleted' and `created' events. > In the same directory, there _is_ a 'renamed' event. We are > discussing a situation when a file was moved to another directory, > which is not what this scenario is about. A handler of an application always knows which directory it is watching. Where's the problem? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 12 04:44:28 2015 Received: (at 21435) by debbugs.gnu.org; 12 Sep 2015 08:44:28 +0000 Received: from localhost ([127.0.0.1]:57600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZagQ7-0003Tc-Sr for submit@debbugs.gnu.org; Sat, 12 Sep 2015 04:44:28 -0400 Received: from mout.gmx.net ([212.227.15.15]:55805) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZagQ5-0003TU-T7 for 21435@debbugs.gnu.org; Sat, 12 Sep 2015 04:44:26 -0400 Received: from detlef.gmx.de ([93.209.76.37]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lrek1-1YdsE60DNd-013KAu; Sat, 12 Sep 2015 10:44:23 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <83k2s07vaf.fsf@gnu.org> <87fv2ovlcr.fsf@gmx.de> <83613k7owe.fsf@gnu.org> <87si6og17z.fsf@gnu.org> <877fnzv4r6.fsf@gmx.de> <87egi7o1s1.fsf@gnu.org> <871te7tk9i.fsf@gnu.org> <87oahatt4p.fsf@gmx.de> <87a8sunve8.fsf@gnu.org> <87si6mi2oy.fsf@gmx.de> <87613inkpx.fsf@gnu.org> <87r3m5l1sk.fsf@gmx.de> <87a8st9mm8.fsf@gnu.org> Date: Sat, 12 Sep 2015 10:44:22 +0200 In-Reply-To: <87a8st9mm8.fsf@gnu.org> (Tassilo Horn's message of "Fri, 11 Sep 2015 14:17:03 +0200") Message-ID: <87y4gchvrt.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:TYCfQGXIpjmaZdrMzLL78b/Jdi+9dMr72pyaA0wot617qPWP7br y3DXLGrCa5jH7+xYvcVpsgkCjW4NEEj+AtlxFMrVHDWouOEfPIJptguogsJTkWY3sYJhzOQ ofp//43snXqhlUz2EX58+xCCwanORuHBeFKqmd8i7nBbgGA7vjcHEZ0oRvGZewr/cl986Uk /tWjnJOOrmcrmATB84oIg== X-UI-Out-Filterresults: notjunk:1;V01:K0:CW9Nrtc1ev4=:aGlyLoQnGUfzTUV+93Rqtf KN8x6cfiPrfENxAmt+6oli09iKdTsZamZZdVqKmo8MZZn4gzL02VMYcN7+TwyUqmBPqDKsdsu Ykz3Yv+cIQ4FyvEm93YyQk6tku1vDOAo5C6rsLQFTuYJtTgArlqh4kUlzuB6U9xXrsEXN6CoU FEcyIeWWmZSvLikXroJ0KsqEtgKGPrPo8q1Yi1lRfGN4j73WF9X4UbaSWcH1prPIqopqeGOTU X8AD4/5r1n01x00rPcOFND4wWY5+lhIamuKxMUke34qPPCyUg6AHXVndNlB2kjXsQorPGXLYd XWjKa415G0J4h8UUjd84i5MhafUqopdYL/wZnxyAHgxD8EnJfOMDElYFiRdmwGjzpI3x67dq+ KMQAfr5JkYCOcEqQiRXIkaXp7EuwgQqh3qJezDFftWJuFQ/NMUXBLE6W7IuBiaDzUDBwlLzzU YdqMhjp9ORaDgCrmlzW/bkNOTAul4GF8g5BzViOVBFPRKj3sCCDUuB6Ygedl5gyy1lEuwGCVs JNSMPfuzoAERXp3vddusz8rps9Ov/xzEWLkVslI5hsa0XTsW/RXQkZ2+XwmVI+RL+WDyml31Q 9QNQRwJMsCzmCM7JSekHqQWZVuch01rIyapJpkKbLD3aCcgDWM86xqqinVeYqV5C3Vk3tJywD +cBJLpAIgnqglnzTTdGFo8o88fHUVdjJcvrmsoMK4EuQWOqttoXSsvToF7VLSq9Oas7+uLTgq UVTUouZTPtOnd/yjXSbiJy4z8pxCD2LX+SirTQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: Eli Zaretskii , 21435@debbugs.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 (/) Tassilo Horn writes: >>> Hm, then I wonder what causes these extreme delays here. The remote >>> autorevert test really takes at least 20 seconds here. But I have no >>> issues using TRAMP with its ssh method for accessing really remote >>> files... >> >> Now I see it also, but only when running in interactive mode. In batch >> mode, there is no serious delay. Will contact the Tramp maintainer, again. > > Yes, you are right. I always executed the test interactively and now > tried running them from the command line. Indeed, that's way faster. Should be fixed now. The problem was due to the curly quotes in the *Messages* buffer; something I've never understood why it is needed. > Bye, > Tassilo Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 20 13:26:25 2015 Received: (at 21435) by debbugs.gnu.org; 20 Sep 2015 17:26:25 +0000 Received: from localhost ([127.0.0.1]:39000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdiNd-0007MP-CC for submit@debbugs.gnu.org; Sun, 20 Sep 2015 13:26:25 -0400 Received: from mout.gmx.net ([212.227.15.15]:49875) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdiNb-0007MH-Gd for 21435@debbugs.gnu.org; Sun, 20 Sep 2015 13:26:24 -0400 Received: from detlef.gmx.de ([87.146.53.101]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0McmFl-1ZMK7T2yUT-00HwiI; Sun, 20 Sep 2015 19:26:22 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> Date: Sun, 20 Sep 2015 19:26:21 +0200 In-Reply-To: <87y4gh47sr.fsf@gnu.org> (Tassilo Horn's message of "Tue, 08 Sep 2015 10:47:00 +0200") Message-ID: <878u81ngsi.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:qVagcbE9tOdI/fm2w+3wBtt64qXEJS5t1pWqjmTqK0cCw76JkjM rLoXdAP1C9+9RZgI9hKMDpftvnlNLmqy7aTL8Kmjrf9Vtke/R+9/ZCM5jdwiWNBwiodQLny AhoneRHaZjQNMmlabXqxsfcF0akQOoRYLQKtv1CZ1T6j+q+QxjiRXPhofCtr0OrKhQREXQz LlpZpDOBSF+HHAuN3ToTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:QbOBiDQsFeQ=:Gs3AI/TDjBK6ODWbOX3kPW 5uoQYxLdh77pNwX0TZYISuFeenTwelygLZN1ZZywgL/Z8ItQuzjcUejOdtZReDgREnvBEvPfA v4d+hocMb7JEGwCSZ9I9umM/12q4Yfv/eFig+2K5nMLx6Kp8OX/xrBVmkZMhfl5dg6+Ait/sK gP3YUW4zti1+LR2WcS7HG9HRviMIfJjrSnOSxGl3/+UQD9tgVX3M9/pChaD7KQA9xFtMk/pQg 5yFRqY91mGONyK0LAULQKQEpizmZ3o1xYjidg/h/suLHAvjRqom4E1KNX+f6JRL+0q8gG5wSG QIqEDBlFCt6aGwfIwcNyW/uJrCWl++j/rzl+Xsq6fViawS39iEw6EMOE40FzHfQIpw34K9DHj L0nYYBoYwgugQ1RpX4XZlS1u7oKJWpCLZkZt/YGk1kpDkgt105se688Wp53Xu+ddycMKn09dh rUWu8D3CHYQeNx+3tVoos7CL1htJOAPlrK7gf0RWbzO6yi7vtMxsAuyQ+NExzB0ro0F0lUsEU l2nLAG9wxdNusiLBcItpkQ6XH03yQIc0aXYwH2eim6Px+ggmBivvNLGusgHEcC4c0eef8jYig RlrDwd8c7aM3zg5eF+0S7knUE2VvPZ5ea2JGed3uUxS1pn+m937+95M3/Kgmf++xq48HFh6HZ XAYJrEX8SH4/INEJ9HDp+VHwQavB9iIW+Tt9pVoYxoH3McH0fgvrgDg51oJcTk4mHbrjnca5Z zIqaSTSS7yhtLvQ3MyM1o8Snq9+Y9juN+E102A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.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 (/) Tassilo Horn writes: > file-notify using the inotify backend reports wrong events after > directory renames. This is also fixed, the test case for inotify and Tramp pass. So the bug report could be closed once there is a final confirmation for w32notify. Changes for the gfilenotify case will follow. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 20 15:38:11 2015 Received: (at 21435) by debbugs.gnu.org; 20 Sep 2015 19:38:11 +0000 Received: from localhost ([127.0.0.1]:39143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdkR9-000245-8k for submit@debbugs.gnu.org; Sun, 20 Sep 2015 15:38:11 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:47329) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdkR5-00023v-27 for 21435@debbugs.gnu.org; Sun, 20 Sep 2015 15:38:08 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NUZ00P00Q4L7Z00@mtaout24.012.net.il> for 21435@debbugs.gnu.org; Sun, 20 Sep 2015 22:29:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUZ00O7YQ4LSI00@mtaout24.012.net.il>; Sun, 20 Sep 2015 22:29:09 +0300 (IDT) Date: Sun, 20 Sep 2015 22:36:29 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <878u81ngsi.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83y4g0opc2.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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:26:21 +0200 > Cc: 21435@debbugs.gnu.org > > Tassilo Horn writes: > > > file-notify using the inotify backend reports wrong events after > > directory renames. > > This is also fixed, the test case for inotify and Tramp pass. So the bug > report could be closed once there is a final confirmation for w32notify. w32notify reports 2 changed events in a row: Test file-notify-test02-events condition: (ert-test-failed ((should (equal '... (mapcar ... events))) :form (equal (created changed deleted) (created changed changed deleted)) :value nil :explanation (proper-lists-of-different-length 3 4 (created changed deleted) (created changed changed deleted) first-mismatch-at 2))) This is the "copy" part of the test. Interestingly, sometimes there are 2 separate "changed" events and sometimes only 1. Does filenotify.el try to conflate several consecutive events of the same kind into one? In any case, I guess we will have to allow either one or 2 "changed" events there. The other parts also have differences. Here are the diffs I need to make all the tests pass: diff --git a/test/automated/file-notify-tests.el b/test/automated/file-notify-tests.el index 9d66f03..1aaf4b7 100644 --- a/test/automated/file-notify-tests.el +++ b/test/automated/file-notify-tests.el @@ -286,7 +286,7 @@ (ert-deftest file-notify-test02-events () (file-notify--test-with-events 3 (file-notify--test-timeout) (lambda (events) - (should (equal '(created changed deleted) + (should (equal '(created changed changed deleted) (mapcar #'cadr events)))) (write-region "any text" nil file-notify--test-tmpfile nil 'no-message) @@ -318,7 +318,7 @@ (ert-deftest file-notify-test02-events () (file-notify--test-with-events 2 (file-notify--test-timeout) (lambda (events) - (should (equal '(attribute-changed attribute-changed) + (should (equal '(changed changed changed) (mapcar #'cadr events)))) (write-region "any text" nil file-notify--test-tmpfile nil 'no-message) @@ -331,9 +331,9 @@ (ert-deftest file-notify-test02-events () ;; `file-notify--test-events' has been set correctly. (should (equal (mapcar #'cadr file-notify--test-events) '(created changed deleted - created changed deleted + created changed changed deleted created changed renamed - attribute-changed attribute-changed))) + changed changed changed))) (should file-notify--test-results) (dolist (result file-notify--test-results) From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 02:26:05 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 06:26:05 +0000 Received: from localhost ([127.0.0.1]:39407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZduY8-00007H-5o for submit@debbugs.gnu.org; Mon, 21 Sep 2015 02:26:04 -0400 Received: from mout.gmx.net ([212.227.17.20]:54974) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZduY5-00006s-QR for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 02:26:02 -0400 Received: from detlef.gmx.de ([87.146.36.207]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MYsEZ-1Z8L1Y1kyx-00VkQU; Mon, 21 Sep 2015 08:25:59 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> Date: Mon, 21 Sep 2015 08:25:58 +0200 In-Reply-To: <83y4g0opc2.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Sep 2015 22:36:29 +0300") Message-ID: <87mvwge1ah.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:NT6+Saujvb0qffFN5l5dLvEaVfTxfxLPu0UAu4MohKTEbocYYCl h+zOvNTybXvPv5zvVh9+6zA/+jEjG+rzem1X86ZB5DK2GR0NqvMGry65X8tY3XFRca91NLV Owqf4XXW2OOKykVsPhh72EhjR5HZZLtIljbiCoRtMR0xJ+pXz/fwUGU4lqrHdsj8I/Vn6o9 qyGcDO2rKYq26qltbPA4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lb/Xv1pag2U=:lxCP+Pq42lTIzAR8DfmO3J mGGoCiodP2JkXOHjTNUG+MAG24WSeuQT8wMXK1PUcEaqdgrCYZ5J0FY8DFw9WUmipAylGHxTn 4NFyv3AlSCLcm7s50/h6iqQK3ZMGzUB+sIwhY/Wy9Y79ai6/Hf03ERc1Wup1GXbwYfIkcNOti tE8s+lu9Bj8cse72P2mJFTQJ0sWixQRp9XzJzcU3hYRUyFwUYoBC+/usIAbgxjJbrYwEyonfe vRFBu0BzI9FMAYDaufi9fpr3/05tqNZbpW/yJ807+WH3qJyq41ElHFxU5tKCUl0p/24nqFIYo natUWoEI0T22kWcKMBI5Lgb6r/ZtOzyiQp00ZJmrh/cNlQ/8z6VcU088wWiz0KY1bPvFq0Wj7 xn4pKKPnB3J0vU320pyfmiatjFJ0/AoxI8EknOaCNMCKblz1pB1IzYUpEQvuEjqHjSqF1cb2X ThwhxPwk+NPlsHu0iLTSsCUF9K2vtioU01zegsdfBcicURhGl4b+98A5ODmqqkboyVyCeGXzQ x45KJzYa3C+18yG1E5mGQoxXyFzCwusqN9K802A9hcLYI3qO+c6buFMO9lWFjNZ057EiPxbMr 5P4iXXJGyYhRdrZL7eEbGXF2LmPFb7sBEZ7yjKuSYf9yPs7Kgv1RrSfZDxET1LWOAb62+ZhxI xt4LFsaJKuHTj++E6maFmyKaV7mzAt/UQwHe93o8Mbu/JrnI9S9tA5W54ePXADZTqhqOq/UEK Z2Pra3wkS5egKh06a1j2rrOd6M3whQ+qZFWu2w== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: Hi Eli, > w32notify reports 2 changed events in a row: > > Test file-notify-test02-events condition: > (ert-test-failed > ((should > (equal '... > (mapcar ... events))) > :form > (equal > (created changed deleted) > (created changed changed deleted)) > :value nil :explanation > (proper-lists-of-different-length 3 4 > (created changed deleted) > (created changed changed deleted) > first-mismatch-at 2))) > > This is the "copy" part of the test. Interestingly, sometimes there > are 2 separate "changed" events and sometimes only 1. Does > filenotify.el try to conflate several consecutive events of the same > kind into one? In any case, I guess we will have to allow either one > or 2 "changed" events there. No, filenotify.el handles them as they are. The only change in the event flow is, when two consecutive deleted+created events are combined to a renamed event. However, as said I have extended the test case a little bit. There are now set-file-times and set-file-modes calls, which shall result in attribute-changed events. And those events shall be suppressed, because we start file notifications with (file-notify-add-watch ... '(change) ...) How does w32notify report attribute changes? Could you, please, call (trace-output 'file-notify-handle-event) and rerun file-notify-test02-events? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 03:54:14 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 07:54:15 +0000 Received: from localhost ([127.0.0.1]:39465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdvvR-00029F-Qt for submit@debbugs.gnu.org; Mon, 21 Sep 2015 03:54:14 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:57752) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdvvP-000296-19 for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 03:54:12 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NV000200OI73D00@a-mtaout20.012.net.il> for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 10:54:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV0001VGOM8IPC0@a-mtaout20.012.net.il>; Mon, 21 Sep 2015 10:54:09 +0300 (IDT) Date: Mon, 21 Sep 2015 10:54:18 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87mvwge1ah.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83lhc0nr6d.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Mon, 21 Sep 2015 08:25:58 +0200 > > However, as said I have extended the test case a little bit. There are > now set-file-times and set-file-modes calls, which shall result in > attribute-changed events. And those events shall be suppressed, because > we start file notifications with (file-notify-add-watch ... '(change) ...) > > How does w32notify report attribute changes? As documented: it returns 'modified'. > Could you, please, call (trace-output 'file-notify-handle-event) and > rerun file-notify-test02-events? The trace for one run is below: ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-from ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-to ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-from ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-to ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-from ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-to ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 added "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-from "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 renamed-to "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 removed "file-notify-test35884xN") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#-emacsa05544") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified ".#file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil ====================================================================== 1 -> (file-notify-handle-event (file-notify (100268128 modified "file-notify-test3588rnH") file-notify-callback)) 1 <- file-notify-handle-event: nil From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 06:13:29 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 10:13:29 +0000 Received: from localhost ([127.0.0.1]:39578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdy6C-0005Qd-O6 for submit@debbugs.gnu.org; Mon, 21 Sep 2015 06:13:28 -0400 Received: from mout.gmx.net ([212.227.15.18]:56481) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdy6A-0005QV-EJ for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 06:13:27 -0400 Received: from detlef.gmx.de ([87.146.36.207]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MH0SI-1ZQErf0e6U-00Dmoy; Mon, 21 Sep 2015 12:13:25 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> <83lhc0nr6d.fsf@gnu.org> Date: Mon, 21 Sep 2015 12:13:23 +0200 In-Reply-To: <83lhc0nr6d.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 10:54:18 +0300") Message-ID: <87a8sgdqrg.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:Ja5K8MfLcaH1zJfm7we0nwksHr4Mo9MyuVuvSUpo+Q/BzMunvH6 R5eIlThi0i1K+9rmlKpBlHtgNAvzXHo6P8kEfEwpmG46ah1PLokHY7DxwLkDXZ7fcZMz8V5 zMcVsgoNzocJLFrm/oN/ZxoVlpu8wvQbgUfo5zxEuoX+bJKpNC0bpZ+6kc+VmW3UvFvKirG 8MzFo9ZgRKACzZ0pFjWqw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Sh27QhWOD0E=:Oz6WG2LcIs8XRle9rrUsYj 8v2lzPVEWCnLwn17+84aeQkqw+iyPmm3z8FubaEpUWudcDZZBfaPjC+hj6jDYhpL8A7RWy8x7 HGE9yKYHAOK+bpZ0aWSPyl42nxaurdgk9eCXTomSTzRY0jN/ll1qIcwpSHAmpG+8yTc+uFDmP zKt3FAOEAdY5M7yMes4XlzEBFjGAH9EOAVyXRtB9qkpJMKrikEPZCiMZ+nxffAPTERXNWl4d2 l41EFV+3x603xxknkA0cEooWC3nVfdOPNaSAWtUZqeUankjmbdjNZTpfkyWUgNqRdfI5096R3 CGn/kS2GRLCnkZ31zviFrgt8/sWcuH91RAXRICPtajCqEt9ZnDIyK5wInF1lNiDylEuwZtrHB siAQD6NmXIrXtHjbG6pKzTRVHer2tB52U6Bsab0O+BCKNWJfFqqQdthE2/a3uakHIFPAN8Wwq xSgFBJ0APuROGDkNDHJ+5T3jBHIKA2anoLX1KH4c427K6IU94195W5IM0LjY52/iqHa5e+GNy nUZZaI3tLeAWA5IlbTNmzyVpr7/624d/X4X6lUeVn3vgxRshhMRqo85HPZMmdd7freDcnZx6n NjyQtdGABc12KDPu5pj+gH3KTg3uoMwlhpyd7Du75U9PtsiBKT4hd+Q2aJp8fUbEuCSp3gwgG tdVWZ0fuT8iKxt2kKvDpwmACnCqx0J3V3BsTYvXbnlKSQUXedi1tNUcAfekJqz3VnLgIiNClR DvrkgqtCzuqiOxFkSxeUPTx+rI0odH4/tqH9VQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: Hi Eli, >> However, as said I have extended the test case a little bit. There are >> now set-file-times and set-file-modes calls, which shall result in >> attribute-changed events. And those events shall be suppressed, because >> we start file notifications with (file-notify-add-watch ... '(change) ...) >> >> How does w32notify report attribute changes? > > As documented: it returns 'modified'. Hmm. So it does not distinguish between "contents changed" and "attribute changed", as the other backends do. What a pity! We must document it then. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 06:14:55 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 10:14:55 +0000 Received: from localhost ([127.0.0.1]:39581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdy7b-0005Su-7b for submit@debbugs.gnu.org; Mon, 21 Sep 2015 06:14:55 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:37674) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zdy7Y-0005Sl-Fa for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 06:14:53 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NV000300V3CT900@mtaout28.012.net.il> for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 13:14:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV000CDBV48F370@mtaout28.012.net.il>; Mon, 21 Sep 2015 13:14:32 +0300 (IDT) Date: Mon, 21 Sep 2015 13:14:51 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87a8sgdqrg.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <836134nko4.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> <83lhc0nr6d.fsf@gnu.org> <87a8sgdqrg.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Mon, 21 Sep 2015 12:13:23 +0200 > > >> How does w32notify report attribute changes? > > > > As documented: it returns 'modified'. > > Hmm. So it does not distinguish between "contents changed" and > "attribute changed", as the other backends do. Indeed, it doesn't. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 09:11:54 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 13:11:54 +0000 Received: from localhost ([127.0.0.1]:39649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze0ss-0002dw-1A for submit@debbugs.gnu.org; Mon, 21 Sep 2015 09:11:54 -0400 Received: from mout.gmx.net ([212.227.17.21]:64876) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze0sp-0002do-H8 for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 09:11:51 -0400 Received: from detlef.gmx.de ([93.209.70.168]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ma2Lr-1Zzol70jhn-00LqjI; Mon, 21 Sep 2015 15:11:50 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> <83lhc0nr6d.fsf@gnu.org> <87a8sgdqrg.fsf@gmx.de> <836134nko4.fsf@gnu.org> Date: Mon, 21 Sep 2015 15:11:48 +0200 In-Reply-To: <836134nko4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 13:14:51 +0300") Message-ID: <87bncvor1n.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:R6oB2UWWlniIcqQD+RG+mqF2XjPYnoXi9YLVSiGrCb23v/ATrRz hxzQOd0uTM42+iC+iA60g0AulLLr1FfFY7u1WGO3tYqA+Ih87SFOkHLJz7StpYSPRsLCmLR wZwWTB2zvPHbYl6+OGQTCxulPxfq6J5eFzZlovIvGpS2fXReSv8YSakCPeqzo3CzYcoz5fj eHahvdV4kpzuaRVso6BSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5PO8j1be+C0=:MbBEsT5CkZUot+plpchxjq qoiY2Yv+SOow59tuMcMSgmdQVC0O6OGQgBN9eHjXgqPrMPgVHtFytvDA2JFIbaYf9t1r3y7uN TmwLM/vvzlGp9XJ4BcRWbdN0hTEHypaCP6TnADywEiESOl5ddQGB5BUfaJ6LSkvGQTyHnmNo4 dn+QkJVcvWB++DR4HUkBZ2iTf7O7e4G4Wp1Wz8JhuP5kBj48j8wDrq6RaqbBTk88XMp0Sv2Cx D0ucGfKm5hEP41EZDydqq4E8r/8gAkJoO1J6a3dKxUVkNrpNhMVqTfhR+rX7CRuJLhlVrCJ87 rgDuNJaI1hQ2j7cAWYfEo8hUAMUsNDcTcv3qIxGZKF1XFj4lfjXbzDXDOp7lEbictkLaXrgMW DD0yTzbou9A6eJ2WlwOozRPMMoXwNMZh0QpBXeqcBJHkB1w+mpfRjpDObay7L8Uy/kLxcOFar gOgHHur5++OVhaAHFIl7RuuFMimG7g/e7eSbAkLvCGBOCUy77XuKmsw6zBeLJ0dOdgS6gAIJQ 5KLo62kb8a4cDyXMzKcrwqGcJgOw1X/amLmqVmmyQ0k+QxglzJMm2jFnCfnVtfTGrxXyqMZpZ GGth7tna3LDH+eVGAhiU5dejkyfjo5GsSZbWVHOn4sHtTQH2ganhCFcma5zRcHc+7ECi4c2/9 AlkyH2ksixCspYdcLA1718GZgMtsHnJQEYNkG9/ymmnhRuuDUsd02gVx5dw1KU4miGHBUftm3 Qf8CMPTppl583NxTYSvc8avF1VqcnkE4QCTeZDb17KBCgqiL5p435LJjdpo= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435 Cc: 21435@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: >> >> How does w32notify report attribute changes? >> > >> > As documented: it returns 'modified'. >> >> Hmm. So it does not distinguish between "contents changed" and >> "attribute changed", as the other backends do. > > Indeed, it doesn't. I've committed a patch, which reflects this in file-notify-tests.el. And I've added also a note about to the manual. Could you, pls, check? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 09:31:52 2015 Received: (at 21435) by debbugs.gnu.org; 21 Sep 2015 13:31:52 +0000 Received: from localhost ([127.0.0.1]:39679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1CA-00038K-S7 for submit@debbugs.gnu.org; Mon, 21 Sep 2015 09:31:51 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:52666) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1By-000381-67 for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 09:31:40 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NV100I003HLJI00@mtaout24.012.net.il> for 21435@debbugs.gnu.org; Mon, 21 Sep 2015 16:24:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV100CIC3WDME60@mtaout24.012.net.il>; Mon, 21 Sep 2015 16:24:13 +0300 (IDT) Date: Mon, 21 Sep 2015 16:31:43 +0300 From: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames In-reply-to: <87bncvor1n.fsf@gmx.de> X-012-Sender: halo1@inter.net.il To: Michael Albinus Message-id: <83vbb3nbk0.fsf@gnu.org> References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> <83lhc0nr6d.fsf@gnu.org> <87a8sgdqrg.fsf@gmx.de> <836134nko4.fsf@gnu.org> <87bncvor1n.fsf@gmx.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21435 Cc: 21435@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 21435@debbugs.gnu.org > Date: Mon, 21 Sep 2015 15:11:48 +0200 > > I've committed a patch, which reflects this in file-notify-tests.el. And > I've added also a note about to the manual. > > Could you, pls, check? Checked, fixed, and pushed. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 21 09:38:31 2015 Received: (at 21435-done) by debbugs.gnu.org; 21 Sep 2015 13:38:31 +0000 Received: from localhost ([127.0.0.1]:39687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1Ic-0003Hh-Ht for submit@debbugs.gnu.org; Mon, 21 Sep 2015 09:38:30 -0400 Received: from mout.gmx.net ([212.227.15.19]:62746) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ze1IZ-0003HY-Cy for 21435-done@debbugs.gnu.org; Mon, 21 Sep 2015 09:38:27 -0400 Received: from detlef.gmx.de ([93.209.70.168]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LanoO-1aONgI0Xbk-00kOba; Mon, 21 Sep 2015 15:38:26 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames References: <87y4gh47sr.fsf@gnu.org> <878u81ngsi.fsf@gmx.de> <83y4g0opc2.fsf@gnu.org> <87mvwge1ah.fsf@gmx.de> <83lhc0nr6d.fsf@gnu.org> <87a8sgdqrg.fsf@gmx.de> <836134nko4.fsf@gnu.org> <87bncvor1n.fsf@gmx.de> <83vbb3nbk0.fsf@gnu.org> Date: Mon, 21 Sep 2015 15:38:24 +0200 In-Reply-To: <83vbb3nbk0.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 16:31:43 +0300") Message-ID: <877fnjoptb.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:X9JLYmHttPcIWwK/usK4RufUL0Yfs7HJio12XsOBVdQ9DuVmJ7r icPVpoPlyCCP+RQlbJ+ZuCqZjaHAWeRAJPN9/uu+jlvRoNFmkACAfnz49VG8EWnudUyUTq6 OXV2URn5mhHIyzF6C9BKDVqjWHWbUdZFgWmyHIOJeSKKhuQ1hpCi44J+hoOBmkK261e5U/Y sMtMb/bYdotAhI9I2MoqA== X-UI-Out-Filterresults: notjunk:1;V01:K0:rKSC36Zcxr8=:mkr0m37C68NvzAW5lPj1t4 8LuvTDJr6NJcmg9FpC8L7TM6LzqMh0+kGZe0Dztns9Tz9VbeXVUh4ILsuQnSHqdS4Q9AFdA1p HSW7I61stgQlGDwFVjaeDpOuI5YF0Ri/8gemQKgfmTXrwJfK21vSj0kNau2/A7hEqog+3TYNY q7SyF8NRsPN6OzHSRwPnrntLAwkboCrMFvl9UE3OiS4kiKfNSYSDUfyZjvrSMjB3GgbX1gvR4 0zaJILq4VVULDwlJMaxBUJfzTFNd8CEHYpXH6yR4jVvNSkpaqV89oSl3N5W+Dso3JVXni3C9S WXVMzrOn/DD/0WS5Xp/WltlDqzpwgbSVO95h1DNLTO3lsoeJlcp2MoQA8Wgd+wSDvjk9l9NfF V7XroXjr6EreYlvquWklYiQqMZZVLgCvrQU7DkdGHg6Kvfb/i7xIKnuC1RzU6fJegDEwHjYYf jsIHxateSQtOuoiSuMXqnn10tIw+N7YnWJnNqKYB/8jbZ1WnorBnp8ITghFc+G0/S2rDDO1um ED308a0LfJyYFLYi1vKsLvptvDc2OMNiy4VQUmmGXwzeubZZoqF2a4QVU/dIqKoT+aQmxsJ2N Wyaa0dEIkz/+yvtmd+4kB7+z28yfqIAO2Lvshgr5GviodS0A8B0pGvWLO0Y7L0a5fRfjzhd8K +Yo6yq/UwuKYFMjO1s55c57LsNn4EWuYsZBRnEz56jw+6tf5f/AFDOvI30YmmW47dppU/woKt 3Svgqh4hqiYTdOzu6y1hthQQrtniX33OhSCj/NCjWVbEeY0MSkTCYXeDyxg= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21435-done Cc: 21435-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: >> I've committed a patch, which reflects this in file-notify-tests.el. And >> I've added also a note about to the manual. >> >> Could you, pls, check? > > Checked, fixed, and pushed. Thanks. I'm closing the bug. > Thanks. Best regards, Michael. From unknown Wed Aug 20 06:40:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 20 Oct 2015 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator