From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.devel Subject: Re: Emacs Hangs on Filesystem Operations on Stale NFS Date: Mon, 11 Jun 2018 14:03:15 +0200 Message-ID: References: <1727545582523435cab149c2bc857b40@alexander.shukaev.name> <288488e642ec1f2ea0d1d15ab5dfe43b@alexander.shukaev.name> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1528718582 6862 195.159.176.226 (11 Jun 2018 12:03:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2018 12:03:02 +0000 (UTC) User-Agent: Roundcube Webmail/1.1.2 Cc: Emacs-devel , emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 11 14:02:57 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fSLXF-0001fP-HW for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 14:02:57 +0200 Original-Received: from localhost ([::1]:48255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSLZM-0004ZW-J6 for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 08:05:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSLXh-0004E9-AT for emacs-devel@gnu.org; Mon, 11 Jun 2018 08:03:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSLXg-0005zL-9Y for emacs-devel@gnu.org; Mon, 11 Jun 2018 08:03:25 -0400 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:44199) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fSLXb-0005qd-QL; Mon, 11 Jun 2018 08:03:19 -0400 Original-Received: from webmail.gandi.net (unknown [10.200.201.13]) (Authenticated sender: forum@alexander.shukaev.name) by relay7-d.mail.gandi.net (Postfix) with ESMTPA id 343BD20004; Mon, 11 Jun 2018 12:03:23 +0000 (UTC) In-Reply-To: X-Sender: emacs@alexander.shukaev.name X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.183.200 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:226195 Archived-At: On 2018-06-11 13:50, Andreas Schwab wrote: > On Jun 11 2018, Alexander Shukaev wrote: > >> On 2018-06-11 13:01, Andreas Schwab wrote: >>> On Jun 11 2018, Alexander Shukaev >>> wrote: >>> >>>> I initiated a discussion back in 2015 [1] about fragility of Emacs >>>> in >>>> terms of filesystem operations on stale NFS. No solution actually >>>> came >>>> out of this discussion. I still find this issue very disruptive. >>>> Yet >>>> another example would be `recentf-cleanup' which is in my case >>>> triggered >>>> on Emacs start up, when the file comes from stale NFS, the >>>> corresponding >>>> `file-readable-p' down the stack will hang indefinitely, and there >>>> would >>>> be no way to unfreeze it apart from issuing 'kill -9' to that Emacs >>>> instance. Don't you people find it unacceptable for the daily >>>> usage? >>> >>> How is that a bug in Emacs if you have stale NFS mounts? >>> >>> Andreas. >> >> I didn't find a word "bug" in that quote. I'd rather call it a >> robustness >> enhancement. By the way, I guess you just don't realize how easy it >> is to >> run into that situation on daily basis. > > Is it? Looks like you have an unreliable NFS server, but that's hardly > Emacs' problem. I have no problem with $HOME on NFS. > > Andreas. Andreas, please let's finish that pointless thread branch. I know what are you getting at but this has nothing to do with the fact that Emacs is fragile to external hang issues. I'm very glad that you have reliable NFS server but the problem in my case has a completely different origin. It's like you're jumping out of your skin to turn that feature proposal down, while I see no valid reasons for your defensive stance given that weak argumentation.