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 19:37:26 +0200 Message-ID: <87wpvyi3ah.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441906702 18825 80.91.229.3 (10 Sep 2015 17:38:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 17:38:22 +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 19:38:12 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 1Za5nX-000379-Fc for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 19:38:11 +0200 Original-Received: from localhost ([::1]:50702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za5nW-0001Lc-SJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 13:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za5nS-0001Kd-Hq for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 13:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za5nO-0003nI-6E for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 13:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za5nO-0003nE-3f for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 13:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Za5nN-0002lN-Qf for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 13:38: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 17:38: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.144190665610589 (code B ref 21435); Thu, 10 Sep 2015 17:38:01 +0000 Original-Received: (at 21435) by debbugs.gnu.org; 10 Sep 2015 17:37:36 +0000 Original-Received: from localhost ([127.0.0.1]:55521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5mx-0002ki-6Z for submit@debbugs.gnu.org; Thu, 10 Sep 2015 13:37:35 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:49784) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Za5mu-0002kZ-P8 for 21435@debbugs.gnu.org; Thu, 10 Sep 2015 13:37:33 -0400 Original-Received: from detlef.gmx.de ([93.209.66.208]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUUWN-1ZA0412eBf-00RJhX; Thu, 10 Sep 2015 19:37:30 +0200 In-Reply-To: <837fny5ldi.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 18:45:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:N0ZHU/vRFrlfRfTMI7/fQOrv/UT5m+ZswITerbCmD5sYn54M0fU YTJqd3f68O0VubmkkXkOZ54wAzqSgvnEcjegB8/pmmjijFisKRt4soiozPV1QcoH5f6utwh Rj3luJu+yVYxQNdwaASULe7elBygSK2Okuaeu1h5Wr4mfZVoKUGwX+BKtref1UblsvYY/8o NNHfdzGmBxBggOUlrmSYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yx4GkmKtCZ8=:pxYM0TAefhqiImCe48TRJ3 TjfoqNlILieJRrcqqekgVMi4F4BKAC1vbdqFPDQqeBOpAn2xVZNCxvRDARToXGN/QcYDSxhZd AxSBIJvzevcp6GvDLxffCmojWfs2r5PsDVv4pSApDBhKlJZ17mI+jIWn4cxMOq4LsbzFBuuST 0AaOKphQ2Fyy4B+6F1El2Xpc43CD5QM9+3RQJ639Ct9nNbMkmFUBvxaaNlI3NohAgrZd03AWz zPjKwZMc1EbChQc5SJvBjdktj2cPEXO62DRZgfJxwKeBrUuDkxUXatlY9KaUTnFl5wuHQk9wQ c90s5jkZAmm5zzSvRdwi/oE0Zs1T28+XWMmYEgM3MxsJ9jOsx0ykhwbnm4aEoHcYSU+ZkKu4n nnJ3hoKjzKn26yG7UeS75ZkhPBmjvZI1N9cvk6onbj+VQEoKd+Zhw/zIbYtwy0+bRp41s9GP0 VzfbBF0xIuscGgQwM+7TfIofagotQwZW0NUt2sYuwmJgUPfxZ61e3TAznxf5ib9tvX1myzeCc ErkoowDXfgdqlt9ogOocb+X7cHIgMuYWXaXcDqUOzCuBPEWJY3Rq5+3sQTysYNB76THHFlLXt 0wkGposCd/VJr7lLOY0WoKsfAhecNSjrYSGBG/hkEXb0MmXHDyhok3vABG1nnVhYXJ6sScyUQ fsGP20XoByz+eqAEhRoWeqe0GDKwqxVPgCWaE2vOM1IXAWn7L9pkHrchKwcKugRAPL8lOysHJ FroYwZKlmSRpWTsd2zcm1QITcveEDW+xKxYSUg== 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:106375 Archived-At: Eli Zaretskii writes: Hi Eli, >> (file-notify (100286608 removed "xxx")) >> (file-notify (100286608 added "xxx")) >> (file-notify (100286560 removed "xxx")) >> >> 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.) Hmm, maybe a bug in the MS Windows library?. However, likely we have no practical problem. The first `removed' event reports the removal of a non-existing file. Nothing a handler shall be concerned about (except the test case Tassilo writes for this ...) >> 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. Of course. inotify does this by adding an additional cookie to the `moved-from' and `moved-to' events. A pair of such events with the same cookie belongs together. See the example I have shown: 1 -> (file-notify-handle-event (file-notify (1 (moved-from) "xxx" 49278) file-notify-callback)) 1 -> (file-notify-handle-event (file-notify (2 (moved-to) "xxx" 49278) file-notify-callback)) > 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. There's no guarantee. We must say that there will be `renamed' events only when possible. And if not, one must expect two events `deleted' and `created', handled by the respective handler. > 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. We will conflate them only when possible. inotify helps us by setting a proper cookie. If w32notify cannot provide this, then we will deliver `deleted' and `created'. > 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. > 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. > Finally, two more comments about this: > . I wish such changes were discussed, and the various alternatives > examined, before the code is changed You are right, as always. I didn't expect that there would be such diasagreement. OTOH, I have encouraged Tassilo to improve file-notify-tests.el just in order to have a common base of understanding. The tested (and suceeded) behaviour will be what low-level libraries and filenotify.el have agreed. > . 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. Essential information, like inotify cookies, will be lost. 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 ... Best regards, Michael.