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:01:14 +0100 Message-ID: <87libzn4qt.fsf@gmx.de> References: <878v819kok.fsf@gmx.de> <83fw28uj9c.fsf@gnu.org> <8338y7vkyx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357916493 19207 80.91.229.3 (11 Jan 2013 15:01:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 15:01:33 +0000 (UTC) Cc: Stefan Monnier , 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:01:50 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 1Ttg7C-0006yY-8K for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 16:01:50 +0100 Original-Received: from localhost ([::1]:56205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttg6w-0002BO-5X for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 10:01:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttg6n-0001pg-PM for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:01:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttg6i-00011T-L2 for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:01:25 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:64218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttg6i-00010r-AG for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:01:20 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LuJ7B-1SwBWT0CFL-011gOU for ; Fri, 11 Jan 2013 16:01:18 +0100 Original-Received: (qmail invoked by alias); 11 Jan 2013 15:01:16 -0000 Original-Received: from p57BB98BB.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.152.187] by mail.gmx.net (mp024) with SMTP; 11 Jan 2013 16:01:16 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19ljawzS19lYcNtAKF092jwE7pRoN41vQ/KgXKadR 5PxTo5rQtNqC+W In-Reply-To: <8338y7vkyx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Jan 2013 16:43:34 +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.18 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:156220 Archived-At: Eli Zaretskii writes: >> > . 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. I can speak only for the inotify case. According to my tests, IN_CLOSE_WRITE will always happen once a file has been written on the filesystem. See for example (commands have been applied in different shells): --8<---------------cut here---------------start------------->8--- ~$ echo xxx >>~/tmp/123 ~$ inotifywait -mq ~/tmp/123 /home/albinmic/tmp/123 OPEN /home/albinmic/tmp/123 MODIFY /home/albinmic/tmp/123 CLOSE_WRITE,CLOSE --8<---------------cut here---------------end--------------->8--- Do you (Stefan?) have a use case where just IN_MODIFY has been fired, w/o a corresponding IN_CLOSE_WRITE? > 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.) Hmm, as said already I have almost no chance to test it under Windows ... I would let this implementation to somebody else. >> 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? The timer is still active. The file watch handler just marks buffers where the related file has been changed. Revert happens when the timer goes through the buffers markes via `auto-revert-active-p'. That sounds like an acceptable compromise. Best regards, Michael.