From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Added inotify support. Date: Sat, 06 Oct 2012 17:39:16 +0100 Message-ID: <87ehlbtv0r.fsf@spindle.srvr.nix> References: <2181827.T3JxG88qQt@descartes> <83lifoa7hr.fsf@gnu.org> <87obkkcu92.fsf@wanadoo.es> <87lifkvoxl.fsf@spindle.srvr.nix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349541563 19491 80.91.229.3 (6 Oct 2012 16:39:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2012 16:39:23 +0000 (UTC) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 06 18:39:29 2012 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 1TKXPV-0004V9-6L for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2012 18:39:29 +0200 Original-Received: from localhost ([::1]:47688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKXPP-0006zB-D8 for ged-emacs-devel@m.gmane.org; Sat, 06 Oct 2012 12:39:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKXPM-0006yv-Ik for emacs-devel@gnu.org; Sat, 06 Oct 2012 12:39:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKXPK-0006Hc-T6 for emacs-devel@gnu.org; Sat, 06 Oct 2012 12:39:20 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:34613 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKXPK-0006E7-I6 for emacs-devel@gnu.org; Sat, 06 Oct 2012 12:39:18 -0400 Original-Received: from spindle.srvr.nix (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id q96GdGMK000138; Sat, 6 Oct 2012 17:39:16 +0100 Emacs: if it payed rent for disk space, you'd be rich. In-Reply-To: (Stefan Monnier's message of "Fri, 05 Oct 2012 14:22:16 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-DCC-STAT_FI_X86_64_VIRTUAL-Metrics: spindle 1245; Body=3 Fuz1=3 Fuz2=3 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 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:154127 Archived-At: On 5 Oct 2012, Stefan Monnier verbalised: >> Of course you can't rely on inotify rather than polling, because inotify >> simply silently omits all changes that come from other hosts when an fs >> is mounted or exported over the network. > > Of course, it also doesn't help when Emacs is built without inotify. > The main questions would then be: > - how often does it work? I think this is likely to be "often" since it > should work for most/all the "home desktop" as well as laptop use > cases. Most, but certainly not all: I have a home desktop, but it so happens that I have my home directory on a separate low-power home server so that I can shut the desktop down when not in use. If I run Emacs on the desktop machine, it's not going to see inotify watches on my home directory -- or, rather, it'll see those performed by the desktop, but not those performed by the server (e.g. email delivery). > - can we reliably determine whether it will work? No :( you get that subset of events that happened on the local machine only, but even I ran Emacs on the server, it would see a local filesystem but would *still* miss events -- those happening on the desktop. > IIUC inotify works reliably for local file-systems (even if they're > exported because the other hosts's actions will be locally performed > by the nfsd) Those don't always appear :( the nfsd doesn't do all its actions at a level that inotify can see, alas, and certainly won't necessarily generate the expected events for them (a touch shows up as an attrib event locally, but an open if it's something the nfsd has done on behalf of a remote client (!).) > but not for file-systems mounted from a remote host. > Can inotify inform Emacs that its notices won't be reliable (so Emacs > can decide to use polling instead)? I don't think so. The answer in any case is 'inotify is never reliable': even if the FS is not exported across the network and never becomes exportted across the network, the queue can fill up and lose events and the like. I really really wish notify worked over the network :( >> inotify and friends are only spying on local VFS traffic, which in my >> experience makes them less than useful for most applications. > > Aren't they used by most GUI file managers? Yes. If you have an NFS-mounted home directory, you get used to hitting refresh in GUI file managers :( inotify basically sucks for these reasons and others, but the kernel people say that they don't care if it doesn't work over the network and that it can't be made to work anyway, and the desktop people who make use of inotify say that nobody uses NFS and everyone just has a single laptop and your use case is out of scope, go away. Meanwhile, Windows does file notification over the net perfectly well and has for years. :( -- NULL && (void)