From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: File watch support in autorevert.el Date: Fri, 11 Jan 2013 16:18:46 +0100 Message-ID: <87ip73n3xl.fsf@gmx.de> References: <878v819kok.fsf@gmx.de> <83fw28uj9c.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357917540 30141 80.91.229.3 (11 Jan 2013 15:19:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 15:19:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 11 16:19:17 2013 Return-path: Envelope-to: ged-emacs-devel@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 1TtgO4-0004X8-Tl for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 16:19:17 +0100 Original-Received: from localhost ([::1]:33609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgNo-0007RY-Ms for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 10:19:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgNg-0007GW-6R for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:18:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtgNe-0005Ov-Tb for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:18:52 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:50361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgNe-0005Oi-Iy for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:18:50 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MEYeV-1TivoJ08wD-00FiDd for ; Fri, 11 Jan 2013 16:18:50 +0100 Original-Received: (qmail invoked by alias); 11 Jan 2013 15:18:49 -0000 Original-Received: from p57BB98BB.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.152.187] by mail.gmx.net (mp035) with SMTP; 11 Jan 2013 16:18:49 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX1+W4qd+zJOW5jp+IRPdkNiXIL4qCNFi5f13jolNhH LR/XzmPILarnBE In-Reply-To: <83fw28uj9c.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Jan 2013 12:05:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156221 Archived-At: Eli Zaretskii writes: > . The code as written is too naive: it blindly assumes that every > single notification reported by the filesystem for a given watch is > necessarily the one requested in the auto-revert-notify-add-watch > call. But that assumption is false, at least on Windows, where the > implementation actually watches events to the entire parent > directory of the file we are interested in. So Emacs reverts the > file whenever _any_ file in the same directory was changed. I > believe similar problems can happen with inotify, albeit much more > rarely. For that reason, I think auto-revert-notify-handler should > filter events by ASPECTS/ACTION member, and on Windows also by FILE > member of the event. Will do for the inotify case. It is a simple bit easier, because you can install a file watch for exactly one file, and you can expect it returns for that file only. This will be different, when we implement `dired-buffer-stale-p' based on file watches. In general, something like IN_DELETE* and IN_MOVE* must be handled properly. That's clearly missing in my first shot. > . It isn't clear to me that using IN_CLOSE_WRITE with inotify is TRT: > AFAIU, that would mean we only revert a file when the application > writing to it closes its descriptor. IOW, if the application makes > several changes to the file during a prolonged operation, and > doesn't close and reopen the file in between, we will only see the > changes at the end, but not during the operation. Wouldn't it be > better to use IN_MODIFY instead? See my other message. I believe IN_CLOSE_WRITE is sufficient for the inotify case, but I might be wrong. I would need a test case which shows it. > . At least on Windows, turning on auto-revert-mode and then modifying > and saving the file announces that it was auto-reverted. This > didn't happen with the auto-revert method that doesn't use file > notifications. Is this a bug? I have an old Emacs instance, w/o support of inotify in autorevert.el. There I see the same message. > . I believe some of the features added to autorevert.el, such as a > hash list of watch descriptors, should be in some infrastructure > with appropriate APIs. Yes. During these tests we want to identify these features. When possible, I will try to add more general functions in autorevert.el, which could be extracted later for a general API. Best regards, Michael.