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 20:20:54 +0200 Message-ID: <87twr29lvd.fsf@gmx.de> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441909617 3535 80.91.229.3 (10 Sep 2015 18:26:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 18:26:57 +0000 (UTC) Cc: 21435@debbugs.gnu.org, tsdh@gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 10 20:26:47 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 1Za6YG-0007GY-5A for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 20:26:28 +0200 Original-Received: from localhost ([::1]:51122 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6YA-0004Cs-K0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 14:26:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6T1-0003b4-KP for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:21:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za6T0-0002hx-Fg for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:21:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6T0-0002hk-56 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za6Sz-0003pT-N1 for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 14:21:01 -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 18:21: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.144190926014704 (code B ref 21435); Thu, 10 Sep 2015 18:21:01 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 18:21:00 +0000 Original-Received: from localhost ([127.0.0.1]:55560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Sx-0003p6-K8 for submit@debbugs.gnu.org; Thu, 10 Sep 2015 14:21:00 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:57739) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za6Sw-0003oy-49 for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 14:20:58 -0400 Original-Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M54L0-1YiYuX0fXy-00zFJd; Thu, 10 Sep 2015 20:20:55 +0200 In-Reply-To: <83wpvy40fa.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 21:03:05 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:1A5M+LSyADHnYHmWUok3oJvmIM/se9UmjqthckvPcpYoGGEJYJu Dsdb6nBDBvaudo9ajlYdEA4jvKlbKFQ4v8ImhR4o8NFVi0i4Siv0CE5GPq+4e7AZA5+db/Q Oc5qzXRXkDPY2DMT7qv8hbmi/xXeB3I7CQ1tRJ53QBRFZp4AtghsDFDKoHD+55HdqD0vhhL gQjlL5RfTKTfrnJsLlz5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:1oEeWHXtirs=:1jQCU0UBiAT99YXEkv069X bpTJGeFWA1MfUq8gB3Pjnxms6v9Nmu7hSulKQqE+blu9fzWoTSkhVb1mgE3W4eNPrWuk3Wdzg CBO0SRMfxzRjnGB3fnRLN14TtngV4QuNzpP6mOUW9stl+rHxu1voNHacYD2nnnQSVlHHlKWcJ Z4b7tANaW3KwmI8SywoaEGZ0Oc9B1d1tMa4tAwEY2rBAl6orKXHPYFp9z7BpyAvyfnbwaLRYc qHqQsu4bMgjZ91ZrFg9gnXLL32Vz+QiAhv1WsGlYqN8Z2TfkpukcALSxn+B9sL2SmXAAd2x6V soAWbLIdwpjSQVf2yQM7dY9fbqzLFQ9rqhCvT+3eYXtW8FlzfZEjls5lXjacofUWVDX8EbRMI GofeC1NxJGwJQ0UtVDv9UNgyEvkc43mONwrlcpizvOMKoxlhns+Ilp0smSfdUzLrT9SMuubRQ Sf6XWHq7syAwQObm8+leMfY7yoejh+vgdGGQIBghXpYh0mAauQoZ08Om384eEpI14wZr7AgP8 C9BVcOsKunh0In7O0Y6Ly9hiTYeHcf11/rd5dB4W4bk4EfVAKiguZpf63RtttfsG1gdTo1uOn FVcSJ+Tp43QWXyEGGYVxgyz5Zg+C7BOUbHLVQiJg+4DXH4lS92/8b+rsDakfZTnLz0khQPQhW 4pWmBraUc3lu29epmApFNRJ72kvPNy0Nsis2vRSmbSWg3SrMtjeGa3P+tE0PHVMIdroJ/+1/f 6uR08GuIL4XCIIUU873SWpco60nQucaEtzp0/A== 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:106383 Archived-At: Eli Zaretskii writes: >> > 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. For that dired case, yes. I was answering to your statement "if all we want is to make sure the destination directory ..." >> 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. Maybe, I haven't checked. But the point is that we send a `renamed' event only we can trust there is a file move. Otherwise, we send `deleted' and `created'. >> > . 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. Because we got it from gfilenotify, because we could pair the events via inotify cookies, whatever. When it is not reliable, we send `deleted' and `created', which has less semantics than `renamed'. > 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. >> 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'? This would reduce the information. >> 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? Best regards, Michael.