From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21435: 25.0.50; file-notify has problems after renames Date: Thu, 10 Sep 2015 18:45:13 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441900013 538 80.91.229.3 (10 Sep 2015 15:46:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 15:46:53 +0000 (UTC) Cc: 21435@debbugs.gnu.org, tsdh@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:46:43 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 1Za43F-0002iC-T2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 17:46:18 +0200 Original-Received: from localhost ([::1]:49962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za43F-0004i4-Cx for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 11:46:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za436-0004hA-Lb for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:46:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za430-0002LV-Lm for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:46:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za430-0002LM-ID for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za430-0005Gg-Ai for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 11:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Sep 2015 15:46: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.144189993720215 (code B ref 21435); Thu, 10 Sep 2015 15:46:02 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 15:45:37 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <87si6mttsf.fsf@gmx.de> X-012-Sender: halo1@inter.net.il 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:106350 Archived-At: > 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