From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: auto-revert-mode and tramp file handlers Date: Tue, 11 May 2004 23:45:47 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200405120445.i4C4jle15322@raven.dms.auburn.edu> References: <200405091734.i49HYRM01844@raven.dms.auburn.edu> <87isf4zajy.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1084337275 32503 80.91.224.253 (12 May 2004 04:47:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 04:47:55 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 12 06:47:50 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNleo-0007eV-00 for ; Wed, 12 May 2004 06:47:50 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNlem-0005WS-00 for ; Wed, 12 May 2004 06:47:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNleI-0006go-FG for emacs-devel@quimby.gnus.org; Wed, 12 May 2004 00:47:18 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNle9-0006dm-I3 for emacs-devel@gnu.org; Wed, 12 May 2004 00:47:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNld1-0006Ci-1f for emacs-devel@gnu.org; Wed, 12 May 2004 00:46:30 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNlcw-00069o-3N for emacs-devel@gnu.org; Wed, 12 May 2004 00:45:54 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i4C4joTS004456; Tue, 11 May 2004 23:45:50 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i4C4jle15322; Tue, 11 May 2004 23:45:47 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: kai@emptydomain.de In-reply-to: <87isf4zajy.fsf@emptyhost.emptydomain.de> (message from Kai Grossjohann on Mon, 10 May 2004 15:17:05 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23215 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23215 Kai Grossjohann wrote: I'm not sure how to change Tramp to make this better: it often happens that a connection is closed merely because a timeout has expired. In that case, just silently reopening the connection appears to be the right approach. But I confess that I haven't thought a lot about your problem. So it's quite likely that there are good solutions that I'm not seeing. But I do realize that there is a problem here. Perhaps it is best to make it easy for the user to customize "no auto-revert on remote files". What do people think? Not just auto-revert, but _very many_ places in the Emacs code call file-exists-p and its many friends in situations where the file usually is local but could be remote. Usually, the purpose seems to be to prevent a relatively time consuming operation and/or prevent an error, in case the file does not exist (or is not readable or whatever). I do believe that in many of these places, the person who put in those calls did not realize that that call could take more than a full minute of real time, regardless of the CPU power of the machine, and could then throw an error instead of returning nil if the file "does not exist" (because of being unreachable). One interpretation is that all such calls are bugs that one way or the other should be fixed. (Presumably by calling file-remote-p before calling file-exists-p and friends, and doing something ad hoc if the return value is t.) Another interpretation is that a handler for these functions should not take a full minute of real time and should not throw an error when the docstring suggests a return value of nil. Is there no way that tramp could detect that the user is off line in a fraction of a second (as ssh apparently can) and if so, return nil for file-exists-p and other functions that expect a return value of nil in this case? Sincerely, Luc.