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:55:38 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441911388 32708 80.91.229.3 (10 Sep 2015 18:56:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 18:56:28 +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:56:17 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 1Za711-0002gf-M8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 20:56:11 +0200 Original-Received: from localhost ([::1]:51250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za711-0005H6-5g for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 14:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za70w-0005Dm-52 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:56:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za70s-0004iT-4b for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:56:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za70s-0004iO-1v for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za70r-0004ex-Pz for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:56:01 -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:56: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.144191135217896 (code B ref 21435); Thu, 10 Sep 2015 18:56:01 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:55:52 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <87twr29lvd.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:106385 Archived-At: > 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.