From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: File watch support in autorevert.el Date: Fri, 11 Jan 2013 16:43:34 +0200 Message-ID: <8338y7vkyx.fsf@gnu.org> References: <878v819kok.fsf@gmx.de> <83fw28uj9c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1357915404 8048 80.91.229.3 (11 Jan 2013 14:43:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 14:43:24 +0000 (UTC) Cc: michael.albinus@gmx.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 11 15:43:41 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 1Ttfpc-00083b-FF for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 15:43:40 +0100 Original-Received: from localhost ([::1]:35682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfpM-0007Od-IO for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 09:43:24 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfpG-0007NN-Oc for emacs-devel@gnu.org; Fri, 11 Jan 2013 09:43:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtfpE-0003jw-Ri for emacs-devel@gnu.org; Fri, 11 Jan 2013 09:43:18 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:63608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfpE-0003jT-Cd for emacs-devel@gnu.org; Fri, 11 Jan 2013 09:43:16 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MGG00B00U3IPW00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Fri, 11 Jan 2013 16:43:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG00BG1U80HB90@a-mtaout23.012.net.il>; Fri, 11 Jan 2013 16:43:13 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:156218 Archived-At: > From: Stefan Monnier > Cc: Michael Albinus , emacs-devel@gnu.org > Date: Fri, 11 Jan 2013 09:34:33 -0500 > > > . 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. > > That seems like a good candidate for something the common API could > hide/provide, I think. I agree. > > . 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? > > For auto-revert-tail-mode, IN_CLOSE_WRITE is definitely insufficient > since the common use case is when we watch a log file, so the CLOSE may > never happen. > > The non-inotify code does something akin to the IN_MODIFY, indeed. I would suggest adding the 'size' filter as well, because Windows doesn't update the last write time on every write to a file, only after many writes. (It does similar filtering with updating the directory entry of the file, so 'size' alone will not do.) > But at the same time, it's often preferable to wait a bit longer for the > application to finish writing the new version of the file. I think the > perfect behavior lies somewhere in-between: when we get an > IN_CLOSE_WRITE, we should revert immediately, but when we get an > IN_MODIFY we should revert "soon". You mean, with a timer?