From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: backup-by-copying-when-mismatch (was: bug#7289: Tramp changes ownership of remote file when saving) Date: Mon, 01 Nov 2010 10:12:31 -0400 Message-ID: References: <874oc6ze69.fsf@gmx.de> <87k4kxzefl.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1288620777 24460 80.91.229.12 (1 Nov 2010 14:12:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 1 Nov 2010 14:12:57 +0000 (UTC) Cc: Jo Vermeulen , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 01 15:12:51 2010 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.69) (envelope-from ) id 1PCv7t-0003F9-Hh for ged-emacs-devel@m.gmane.org; Mon, 01 Nov 2010 15:12:45 +0100 Original-Received: from localhost ([127.0.0.1]:51861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCv7s-0007J3-Pg for ged-emacs-devel@m.gmane.org; Mon, 01 Nov 2010 10:12:44 -0400 Original-Received: from [140.186.70.92] (port=49036 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCv7i-0007Hb-7v for emacs-devel@gnu.org; Mon, 01 Nov 2010 10:12:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCv7g-0007gE-Pd for emacs-devel@gnu.org; Mon, 01 Nov 2010 10:12:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:18100 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCv7g-0007fq-Mn for emacs-devel@gnu.org; Mon, 01 Nov 2010 10:12:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4IAMtnzkxFpZAX/2dsb2JhbACgW3xyvDeFRQSSKw X-IronPort-AV: E=Sophos;i="4.58,273,1286164800"; d="scan'208";a="81254888" Original-Received: from 69-165-144-23.dsl.teksavvy.com (HELO pastel.home) ([69.165.144.23]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 01 Nov 2010 10:12:32 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DD9BDA862F; Mon, 1 Nov 2010 10:12:31 -0400 (EDT) In-Reply-To: <87k4kxzefl.fsf@gmx.de> (Michael Albinus's message of "Mon, 01 Nov 2010 08:33:02 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:132235 Archived-At: [ Moving this to emacs-devel. ] >> 2 problems with this patch: >> - (put 'permanent-local t) should *never* be in such a function. >> It's a top-level operation that has global effects and belongs right >> next to the var's defvar. > I want to have `backup-by-copying-when-mismatch' buffer local. If I set > it in `insert-file-contents' (via `make-local-variable'), it is not kept > buffer local in that buffer. How could I achieve this otherwise? You could place the `put' in files.el at toplevel, right next to the definition of backup-by-copying-when-mismatch. >> - This makes it impossible to choose backup-by-copying-when-mismatch=nil >> when accessing such remote files, whereas for local files accessed by >> root a (setq backup-by-copying-when-mismatch nil) in the .emacs will >> do the trick. > D'accord. We would need another way for the user to express his > wish. Maybe there shall be also other values but only than nil and t. That would be an option, indeed. >> A simpler solution would be to change the default value of >> backup-by-copying-when-mismatch to t for everyone rather than just >> for root. I don't know what would the objections to this. > From my pov it would be acceptable, but I don't know how people see it. Neither do I. > And we should check what it does mean for remote files, because they > tend to "mismatch" more often. That's a very good point. Stefan