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 17:50:42 +0200 Message-ID: <83y5fzu3al.fsf@gnu.org> References: <878v819kok.fsf@gmx.de> <83fw28uj9c.fsf@gnu.org> <8338y7vkyx.fsf@gnu.org> <87libzn4qt.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1357919430 17313 80.91.229.3 (11 Jan 2013 15:50:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 15:50:30 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 11 16:50:47 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 1TtgsY-0005qs-Sn for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 16:50:47 +0100 Original-Received: from localhost ([::1]:34965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgsI-0000iI-W1 for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 10:50:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgsE-0000hh-Ec for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:50:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtgsC-00062m-HV for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:50:26 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:35916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgsC-00062V-27 for emacs-devel@gnu.org; Fri, 11 Jan 2013 10:50:24 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MGG00B00X1NZD00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Fri, 11 Jan 2013 17:50:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG00BKMXBWYS30@a-mtaout23.012.net.il>; Fri, 11 Jan 2013 17:50:21 +0200 (IST) In-reply-to: <87libzn4qt.fsf@gmx.de> 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:156222 Archived-At: > From: Michael Albinus > Cc: Stefan Monnier , emacs-devel@gnu.org > Date: Fri, 11 Jan 2013 16:01:14 +0100 > > >> 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): The documentation (inotify(7) page) clearly says IN_CLOSE_WRITE File opened for writing was closed > --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? Maybe I'm missing something, but the above example is not the issue at hand. The issue at hand is to have several separate writes to a file with some significant time between them. AFAIU, in the above example the file is written once and then closed. > > 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. So now we will have features which, although equivalent, are only implemented on the platform of the implementer's choice? If so, what good is it to have the same feature implemented on different platforms?