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: Emacs tramp troubles with old Sun Date: Mon, 12 Nov 2007 21:23:35 +0100 Message-ID: <87mytjusag.fsf@gmx.de> References: <87bqa5ye3a.fsf@gmx.de> <87wsstb6ca.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1194899030 17446 80.91.229.12 (12 Nov 2007 20:23:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2007 20:23:50 +0000 (UTC) Cc: bob@rattlesnake.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 12 21:23:54 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Irfop-0005Ho-RJ for ged-emacs-devel@m.gmane.org; Mon, 12 Nov 2007 21:23:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Irfod-0005M2-AO for ged-emacs-devel@m.gmane.org; Mon, 12 Nov 2007 15:23:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Irfny-0004Kj-R8 for emacs-devel@gnu.org; Mon, 12 Nov 2007 15:22:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Irfnu-0004FV-To for emacs-devel@gnu.org; Mon, 12 Nov 2007 15:22:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Irfnu-0004FB-NB for emacs-devel@gnu.org; Mon, 12 Nov 2007 15:22:42 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Irfnu-00059K-6o for emacs-devel@gnu.org; Mon, 12 Nov 2007 15:22:42 -0500 Original-Received: (qmail invoked by alias); 12 Nov 2007 20:22:39 -0000 Original-Received: from p57A21C3E.dip0.t-ipconnect.de (EHLO arthur.local) [87.162.28.62] by mail.gmx.net (mp029) with SMTP; 12 Nov 2007 21:22:39 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18ihYwTeuQiDXDi0dP7/uuOjeHGFYialUwvcknSUp I+3MxFCwLe+NBe In-Reply-To: (Michael Albinus's message of "Thu, 08 Nov 2007 16:21:55 +0100") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:83080 Archived-At: I wrote: > Stefan Monnier writes: > >> Would it be possible for Tramp to detect the "test: argument expected" error >> message and force a "cleanup-connection" at that point? >> [ and of course, do similar things wherever applicable: the idea is to try >> and detect when the cached properties become invalid, which will >> necessarily happen over time as machines get upgraded/replaced/... ] > > Exactly the same idea I'm just thinking about. But one must ensure > there's no infloop - when "test" does not work, it could be another > reason but invalid cached values. One shall remember the reason for > calling cleanup-connection, and when the same problem appears again, > it's time to give up. > > Another idea is to keep a counter for cached properties. After a while > (100 uses, 100 days, whatever) the values shall be recomputed, just in > case. Think about a changed default $PATH, where it isn't always an > obvious error with the old value, when new directories appear. > > At least when "uname -s -r" returns a changed value, it is time to > expire the cached properties for that machine. Finally, I've implemented only the "uname -sr" check. The other checks for connection properties cleanups I have had in mind are too dangerous. Tramp sends remote commands on the fly (when it is necessary only). Therefore, command sequences are not "atomic" such a way one could just flush the cache, and reapply the command. Another drawback would be that error analysis might be impossible when all relevant data are thrown away once an error happened. The original problem we have spoken about was that Tramp did not recognize shell echoing on the "old Sun". Wrong cache entries were likely a result of _this_ error. I expect to reduce the number of errors in Tramp :-) Such situations should not happen so often in the future. >> -- Stefan Best regards, Michael.