From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21435: 25.0.50; file-notify has problems after renames Date: Thu, 10 Sep 2015 17:31:27 +0200 Message-ID: <87a8sunve8.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441899150 15824 80.91.229.3 (10 Sep 2015 15:32:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 15:32:30 +0000 (UTC) Cc: 21435@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 10 17:32:18 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 1Za3pa-0005Za-Gh for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 17:32:10 +0200 Original-Received: from localhost ([::1]:49873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za3pZ-0002ax-Um for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 11:32:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za3pV-0002Zi-Ba for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:32:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za3pS-0002hT-3Z for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:32:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za3pS-0002hK-1Y for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za3pR-0004wH-UM for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Sep 2015 15:32:01 +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.144189909518943 (code B ref 21435); Thu, 10 Sep 2015 15:32:01 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 15:31:35 +0000 Original-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 Original-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 Original-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) Original-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 Original-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) In-Reply-To: <87oahatt4p.fsf@gmx.de> (Michael Albinus's message of "Thu, 10 Sep 2015 13:23:50 +0200") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106347 Archived-At: 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