From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: error in server-running-p on M$ Date: Sun, 23 Nov 2008 06:32:00 +0100 Message-ID: References: <18728.4982.765983.511070@a1ihome1.kph.uni-mainz.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227418339 22328 80.91.229.12 (23 Nov 2008 05:32:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2008 05:32:19 +0000 (UTC) Cc: Eli Zaretskii , Ulrich Mueller , emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 23 06:33:21 2008 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 1L47ay-0003zp-4n for ged-emacs-devel@m.gmane.org; Sun, 23 Nov 2008 06:33:20 +0100 Original-Received: from localhost ([127.0.0.1]:58126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L47Zp-0006d0-2T for ged-emacs-devel@m.gmane.org; Sun, 23 Nov 2008 00:32:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L47Zi-0006ZU-Kt for emacs-devel@gnu.org; Sun, 23 Nov 2008 00:32:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L47Zh-0006Yb-7X for emacs-devel@gnu.org; Sun, 23 Nov 2008 00:32:02 -0500 Original-Received: from [199.232.76.173] (port=48562 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L47Zh-0006YY-0X for emacs-devel@gnu.org; Sun, 23 Nov 2008 00:32:01 -0500 Original-Received: from rn-out-0910.google.com ([64.233.170.188]:15081) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L47Zg-0007ll-Lg for emacs-devel@gnu.org; Sun, 23 Nov 2008 00:32:00 -0500 Original-Received: by rn-out-0910.google.com with SMTP id k32so1404579rnd.7 for ; Sat, 22 Nov 2008 21:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cd/2ucNCF0hZull/g43Zjp/PhUc2P2ry/8pt81SDVfI=; b=h4omxFlP3bS6/QOS8vNcoFxCEpjaj7ZfZ8KQngqmduUJYGb+D3Tyj06O+4eNQ1TXRf 9RueTWb0MwRlJS0H6Y1Mqp0MFH5+ENHdS9X35eQz1zDtVJ5phqWUsGG6cikGRMCHwrVG w+OmFPXgW9sxyJ8KLvs7kNs+YTUYQ4nd353jM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TbjhSLRD75xM7pQyta4kJm6KFtIMlJMmTdV6AUNIbbb+j6rNWoztqf+Bzf8iJ9PPKD KG+v6iN+rTR4sA2L1kezx3fiMpJittnAxD+7w5kMNJ7FF4+wYxWfXlOtmL4DqFeYx2uI wW6j9ri8jT+c2nppcBSE47P3tOHluV2AGmDF0= Original-Received: by 10.100.143.12 with SMTP id q12mr1007483and.22.1227418320120; Sat, 22 Nov 2008 21:32:00 -0800 (PST) Original-Received: by 10.100.13.13 with HTTP; Sat, 22 Nov 2008 21:32:00 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:106005 Archived-At: On Sun, Nov 23, 2008 at 06:21, Stefan Monnier wrote: > To avoid clobbering 1's auth file. Then, it is not really necessary to connect with 1's server. Just the fact that there's a local Emacs with the same PID that the one saved in the authentication file, and acting as a local server, should be reason enough for 2 to refuse overwriting the auth file. > Assuming that server-start is changed to signal an error if > server-running-p returns non-nil, could you show us again the scenario > where the auth file is clobbered and in what way it's clobbered? No, I've never claimed that. If server-start signals an error when `server-running-p' returns non-nil, the auth file won't be clobbered. (At least, in normal configurations; I'm not sure that is impossible for some combination of non local servers, remote home user directories, etc. That's left as an exercise for the people who usually works in such environments ;-) But we're trying to fix the easy, common problem first, aren't we? Juanma