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 12:05:51 +0200 Message-ID: <83fw28uj9c.fsf@gnu.org> References: <878v819kok.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1357898761 11266 80.91.229.3 (11 Jan 2013 10:06:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 10:06:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 11 11:06:19 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 1TtbVC-0000T3-Hv for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 11:06:18 +0100 Original-Received: from localhost ([::1]:57309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtbUt-0002Wa-J5 for ged-emacs-devel@m.gmane.org; Fri, 11 Jan 2013 05:05:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtbUn-0002Tj-JU for emacs-devel@gnu.org; Fri, 11 Jan 2013 05:05:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtbUl-0002f8-7x for emacs-devel@gnu.org; Fri, 11 Jan 2013 05:05:53 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtbUk-0002ek-RE for emacs-devel@gnu.org; Fri, 11 Jan 2013 05:05:51 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGG00900HBIBV00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 11 Jan 2013 12:05:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG0090VHD67B30@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 12:05:30 +0200 (IST) In-reply-to: <878v819kok.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.172 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:156210 Archived-At: > From: Michael Albinus > Date: Thu, 10 Jan 2013 15:28:27 +0100 > > As a proof of concept, I have installed a patch in autorevert.el > implementing file watches. This shall work for `auto-revert-mode' and > `global-auto-revert-mode' for buffers visiting files. > `auto-revert-tail-mode' is not supported (yet). Thanks. > The implementation uses `inotify-*-watch' functions. I have also added > the calls for `w32-*-watch' functions, but this is untested. The functions' names are w32notify-*-watch. I fixed that in the trunk revision 111482. I also did some simple testing, and it seems to generally work (but see the problems described below). > Any feedback is welcome. My feedback is as follows: . 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. . 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? . 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 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.