From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.emacs.devel Subject: Re: save-buffer: avoid data loss on interrupt Date: Wed, 14 Dec 2011 15:40:33 +0100 Message-ID: <87fwgnp672.fsf@rho.meyering.net> References: <87zkf282ht.fsf@rho.meyering.net> <87pqfsqtsj.fsf@rho.meyering.net> <4EE7AF8B.2090303@cs.ucla.edu> <87d3bsqjmm.fsf@rho.meyering.net> <4EE7C7D4.8050206@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323873655 30297 80.91.229.12 (14 Dec 2011 14:40:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2011 14:40:55 +0000 (UTC) Cc: Emacs development discussions To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 14 15:40:50 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Raq0n-0001WF-3k for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 15:40:49 +0100 Original-Received: from localhost ([::1]:48538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raq0m-0000M0-JB for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 09:40:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raq0f-0000Jf-9q for emacs-devel@gnu.org; Wed, 14 Dec 2011 09:40:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Raq0Y-00074C-MR for emacs-devel@gnu.org; Wed, 14 Dec 2011 09:40:41 -0500 Original-Received: from mx.meyering.net ([88.168.87.75]:59967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raq0Y-00073r-DV for emacs-devel@gnu.org; Wed, 14 Dec 2011 09:40:34 -0500 Original-Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 344E060401; Wed, 14 Dec 2011 15:40:33 +0100 (CET) In-Reply-To: <4EE7C7D4.8050206@cs.ucla.edu> (Paul Eggert's message of "Tue, 13 Dec 2011 13:47:00 -0800") Original-Lines: 40 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 88.168.87.75 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146709 Archived-At: Paul Eggert wrote: > On 12/13/11 12:52, Jim Meyering wrote: >> doesn't this deserve to be enabled more often >> than when someone tweaks the break-hardlink-on-save variable? > > I'd like to do that too, but things are a bit tricky here. > For example, what if the file has a special ACL? > Won't that get lost? I can add a test for the presence of an ACL, and handle that just like a hard link count of 2 or greater: resort to the standard, non-atomic code path. >> How about this instead, assuming a file-owner-uid function? >> (or if the two users of file-attributes is an issue, >> we could combine file-nlinks and file-owner-uid into >> a function that calls file-attributes just once) >> >> Sure, this might still change the group, but if that's an issue >> we could compare it to the default group. > > Unfortunately one can't predict the ownership of the new file > so easily. It might be a setuid directory; on some hosts, > that causes new files in the directory to have the same > owner as the directory. > > A more reliable way to deal with it might be to create the > temporary file, and ensure that its owner and group > and any other special attributes are correct, before copying to it. > Normally the check should succeed, so this shouldn't cost much > on the average. The permissions should be conservative > (e.g., original permissions sans executable bits) until the > copying is done. That sounds good, but complicates the already hairy logic, since upon mismatch we'd have to clean up and then take the other path. If the cost of an extra stat is not prohibitive, I'm tempted to keep this change simple, check for a set-UID parent directory, and handle that like an ACL.