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: New file notification event `stopped' Date: Sat, 10 Oct 2015 12:13:49 +0200 Message-ID: <87bnc7gheq.fsf@gmx.de> References: <87y4fsqlek.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444472049 22051 80.91.229.3 (10 Oct 2015 10:14:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 10:14:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 12:14:01 2015 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 1ZkrA7-0003Pk-Jz for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 12:13:59 +0200 Original-Received: from localhost ([::1]:44297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrA6-0001So-R1 for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 06:13:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrA3-0001S6-1r for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:13:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkr9z-0001yz-S3 for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:13:54 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:64366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkr9z-0001yp-MI for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:13:51 -0400 Original-Received: from detlef.gmx.de ([79.195.14.202]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MPDaC-1ZgTRG0d60-004SXj for ; Sat, 10 Oct 2015 12:13:50 +0200 In-Reply-To: <87y4fsqlek.fsf@gmx.de> (Michael Albinus's message of "Sun, 27 Sep 2015 11:08:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:7S9EXsI6RpkzbC0nffp9REPULTRiPzp8HgWu2mEcZ9QZH4C5PX/ 4cJURNNE0D1fFX5T+e17EDbuamodRvA8km4GJo8R0loi4NvtZAx/tjf35+Pzrurhsjk1shG yIVlFf1Zi4FMT+O/ipekvwicUrA+Y+7vMs5MJ00d/5RrnkC29LsxRurLVhJp0Hu4ASXhJE2 t9Bir2p9C2VaVpV/Tpe+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:VZTBYF9hVhM=:AAagMoPqj5RNxXbyxfTdDw FgtArpgqM7htEM557G/e6drurw0hkOcTFfwVxWq8JqgGXMoGFYgiP3/vmNYCtw4dXsRmZwQPV jZGI4xKkmKUIK81rMTPJYrJg7Zr4Cv38yxnTNaPOk81n2b//skUbZqU7RtFjKmFLdNhEoX49M FoL3Kt9i/TxDnGNwWg0Y87cypiypCphqa6GW9Zaj7vmgyZue2mlksDLc8nkTS9vTPacLHcfU/ ddr1IvoyStSws0TLxc7+FG6QdzI+fHDubEYoqWYwkI4+fiN7hsu5nz3sPN4RfavDA66PS+8I0 7O4UAGXuLeuGaJWAsu2a8aUzZvzRFlAS+F5KpZcLTAWsBNlO7fgJ59zoOIj62paYttrSO4QKD 2BKeP6Nf4KAb0iG8m8R8Z8RZnd4d/mZe6TFoVopSReaHNFiFOi6epHC+2vyzH4A0w3NJt4q9N rU06IEVTVn2jgAyNJvywj1dbbcqa7ml2D2hCfAEPj1/TD2/rBx0PwKHxmuOaNS5wFtAeYrcHh tQkT30qmNBf9lo9tXEHJz4Bx+q55cXzfcft2Utw4G6B2Ef34sTMCCj5AJUqYGZV2UmQoqQWIr mdulc8rkEK6mD9Vugpf/XWZofq1WvvD8hGER3QmimEmNrw3cxuJ7o+5zF5ma3D3rfoCy6zwtE lEZnAFVHmHu18DX02HdYaWJ9QN12XDwBvUXHy5t72ZszEfiLzBWWdqXi8fs/o3BTf65gx8SvR +/mScVhq6mt/Lazvxyq5im1HyDgq0M0NP0bgZFhBYEjTiJnFWvSkqSC1p0jZSVblsfhJc1XM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.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:191110 Archived-At: Michael Albinus writes: > Hi, Hi, > during the work on bug#21432 and bug#21435, we have introduced a new > function `file-notify-valid-p', which tells whether a given monitor is > still active. We have also discussed shortly, whether a monitor should > signal, when it stops its activities. A monitor could cease to work for > different reasons, maybe because it is cancelled (not only by > `file-notify-rm-watch'), maybe because the file/directory to be watched > is deleted, maybe because some internal limits are reached. > > Therefore, I propose that a new file notification event `stopped' shall > be added to the file notification events to be raised by a file > notification monitor. This would allow applications to react directly on > this situation. For example, `auto-revert-mode' could switch to polling > then. > > The implementation for inotify.c is simple, because it receives already > the native IN_IGNORED event in this case, which could be mapped easily > to the `stopped' event. > > The implementation for gfilenotify.c would create such a `stopped' > event, if one of the native events G_FILE_MONITOR_EVENT_DELETED, > G_FILE_MONITOR_EVENT_RENAMED or G_FILE_MONITOR_EVENT_UNMOUNTED was > received, and the file argument is equal to the watched file or > directory. > > I hope a simlar mechanism could be implemented for w32notify.c. > > Comments? Nobody did reply. So I will implement it next days for inotify.c, gfilenotify.c and Tramp. Maybe Eli could add an implementation for w32notify.c. Best regards, Michael.