From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#21435: 25.0.50; file-notify has problems after renames Date: Thu, 10 Sep 2015 13:23:50 +0200 Message-ID: <87oahatt4p.fsf@gmx.de> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441884268 13186 80.91.229.3 (10 Sep 2015 11:24:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 11:24:28 +0000 (UTC) Cc: 21435@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 10 13:24:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZzxb-0001wY-KT for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 13:24:11 +0200 Original-Received: from localhost ([::1]:48540 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzxa-0002R1-Sh for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 07:24:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzxT-0002Ky-N5 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 07:24:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZzxS-0001hw-Ma for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 07:24:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzxS-0001hs-JV for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 07:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZzxS-0005wT-8n for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 07:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Sep 2015 11:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21435 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21435-submit@debbugs.gnu.org id=B21435.144188423722827 (code B ref 21435); Thu, 10 Sep 2015 11:24:02 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 11:23:57 +0000 Original-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 Original-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 Original-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 In-Reply-To: <871te7tk9i.fsf@gnu.org> (Tassilo Horn's message of "Wed, 09 Sep 2015 22:23:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106342 Archived-At: 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.