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 21:03:05 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441908274 12817 80.91.229.3 (10 Sep 2015 18:04:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 18:04:34 +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 20:04:25 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 1Za6Cf-000203-OI for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 20:04:09 +0200 Original-Received: from localhost ([::1]:50937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6Cf-00084u-9l for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 14:04:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6Cb-00082E-Uv for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:04:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za6CY-0002V5-Gl for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:04:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6CY-0002V1-Dt for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za6CY-0003Og-1m for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:04: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 18:04: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.144190819913008 (code B ref 21435); Thu, 10 Sep 2015 18:04:02 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:03:19 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <87wpvyi3ah.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:106381 Archived-At: > 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.