From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#35418: [PATCH] Don't poll auto-revert files that use notification Date: Mon, 29 Apr 2019 09:19:58 +0200 Message-ID: <87bm0pqnvl.fsf@gmx.de> References: <83sgu71b91.fsf@gnu.org> <74CB5185-5DA1-4786-BD9C-9EEB3D43B3C1@acm.org> <83o94uz9h2.fsf@gnu.org> <875zqzssql.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="206307"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 35418@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 29 09:21:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hL0bF-000rWn-J4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 09:21:17 +0200 Original-Received: from localhost ([127.0.0.1]:53367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hL0bE-0004jB-Ey for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 03:21:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hL0b8-0004j4-3q for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 03:21:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hL0b2-0003is-E7 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 03:21:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52984) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hL0b0-0003iT-Uf for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 03:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hL0b0-0008Ia-Ah for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 03:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2019 07:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35418 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35418-submit@debbugs.gnu.org id=B35418.155652242831835 (code B ref 35418); Mon, 29 Apr 2019 07:21:02 +0000 Original-Received: (at 35418) by debbugs.gnu.org; 29 Apr 2019 07:20:28 +0000 Original-Received: from localhost ([127.0.0.1]:38295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hL0aR-0008HP-RX for submit@debbugs.gnu.org; Mon, 29 Apr 2019 03:20:28 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:44885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hL0aP-0008H8-0b for 35418@debbugs.gnu.org; Mon, 29 Apr 2019 03:20:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556522415; bh=7KLwY7thJwI4MbTWXTxWgqIHT3kdmYBOnFMQ7qt015c=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=O2pmPrYfGIy0WoGcnnK71Oy3VKq7BCsD8z2zai6zJmygI5ZnJH7Q9PipnuyrgHzpC cKQ8i1B6/GvzOYWzL6g0Up7MIQHUmC4mCRExbg8CrGMc7WYM4Wh2Hnz3aQ641H0QiA AyAu5V6cS4xdEEDtHjgTjAyTVwLArrplgZwBUezg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from detlef.gmx.de ([213.220.159.69]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MD9q8-1hZIJv09wC-00GZF9; Mon, 29 Apr 2019 09:20:15 +0200 In-Reply-To: ("Mattias \=\?utf-8\?Q\?Engdeg\=C3\=A5rd\=22's\?\= message of "Sat, 27 Apr 2019 18:19:36 +0200") X-Provags-ID: V03:K1:AQV3FfdiZRLtwgtIGylJmaFuffDTVEaCWRip9G+P99aJE8Eu2jI GGa6DyLNbVaPcjTXAteOqa6/LNekGR6Gp3frwMEfjK+f9ZHVYQyAQkMWNaIo84AIq3xi713 jt/3lLvILOaB0o8af8dr0R+WLToeCNmT0C3EbyJ+PRSL1qHN/I5oMZAdpd0Ompa+B71UpO8 9P27xzfEGiRfcf63qnFHg== X-UI-Out-Filterresults: notjunk:1;V03:K0:FdCkGt2vwWM=:veqU0HTXicyxJCTRPqCGCx RZcRFxRhWJ7V7f8FI2MZoQUeO2JYd2DtyYbEs84Ns/Oz+h/X4spQGX1fpH31GfzyQKqswEzeT 6fEMxm+tTRyTRRP2GrwS0xxT+5eOY9CQ5sWv9f/stoJaOcEvrJsqoo1n8FB8Dhb95whZMpTVy WYjMQ5Xj8FO0TJHtuq3/mhNKnRY8c+9BqOGMtYPg8JQJGO6K7+e1BCmvQkfuXoyTSeK+SZ6OJ UtbAhFoM2mF6QMJEs2IzKvfU8YnUyx3qvOas2LRYASVRifhXQpiwm0ospsN/10/EBDX98FD8l xpLdz3pMR0rc7XGY0c2g3VV8AhsE5AdUcu8jOLwnzv562hchlvcduTNqLb/E2bhOeiRRjkW4N QyOT4W0MwVtGKdFhm5YJ2sMbAL3AvkuouF4KuqX/bokwCBJwU/tsuiMOb8gmZqTFo1PkA+yxJ VfKakkBQ+UWaMNZNfySkP1ChdFgfwA9qnnLv8AyLAukO3ovU2dagADmNt+cM9/t2hEKukSZAj HIMJeKxv+GpjR0PCb8R9M9DDy1BM+IouKULjofQC07Y9PuCv/hrqGgkLYGQ+7tN/0RCaq1z9z VJ4sFSTyeeGhP1PmqkI+C/FBEMbrxxuCik8QxWVnFrXKoKJdyVFWZ/DmbMourtWW8TI77W9+X VJgfOHtjC1BoecwsJt3cfIe6Mvv9hMtDF4m0YViawE/97ou9MFvxi2MuuMl5J8+Pg2xX1i2JO NzCTkMbyTvRBDaOAO2ZPuazej6xxnV1AspKGMm6ryUDiZqoaZuaBXrbtPfWYorl9aoJEIhh6 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158415 Archived-At: Mattias Engdeg=C3=A5rd writes: > Actually, it is (arguably) a bug. With two buffers referring to > distinct hard links for the same file, surely we want a change in that > file to trigger notification for both! (It's quite an exotic case, not > the least because Emacs normally recognises hard links as if they were > the same file name.) By design, in filenotify.el, we want see only events which are related to the file *name*. If you want to be notified for both buffers, you need to watch both file (names). (Well, re-reading the docstring and the manual for `file-notify-add-watch', this isn't said explicitly. Likely, we shall precise this.) > However, with the kqueue back-end, file-notify watches do trigger for > both, as expected. Hmm, this is inconsistent. Worth a buig report? > The reason is that file-notify does not call inotify-add-watch on > individual files, as in your example above, but on their containing > directory ("/tmp" in your example). When monitoring a directory with > two hard links to the same file, and the file is changed, inotify > (sensibly) only reports a change to one of the links (the one employed > for the change). Thus, the logic is in the Linux kernel, not in > filenotify. > > For kqueue it is different: here, changes to files are not reported > when a watch is monitoring their directory, so filenotify.el sets > kqueue watches on each file instead. The same could be done with > inotify (and w32notify, if I read the code right), but watching > directories has certain advantages. It was a design decision, that filenotify.el implements directory watching. Since kqueue does not support this, it must be emulated, somehow. >> One alternative approach could be to analyze the file system device >> number, as returned by `file-attributes'. By this, we could detect >> mounted file systems. > > Sort of; the interpretation is tricky, and as Eli commented, quite > platform-specific. I'm also not in favor of this approach, I just wanted to mention it. >> But I don't believe that this information is always trustworty, given it >> isn't used anywhere. And at least for remote files it doesn't tell you >> anything. Furthermore, mounted file systems are not the only reason that >> file notification doesn't work, and we need to poll. > > What other reasons are you thinking about? The reasons you have already quoted somewhere else: sometimes, file notification is not applicable; there are not enough descriptors left; a file might have been deleted; a file notification process has been killed silently; you name it ... Best regards, Michael.