From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: save-buffer: avoid data loss on interrupt Date: Wed, 14 Dec 2011 10:51:57 -0800 Organization: UCLA Computer Science Department Message-ID: <4EE8F04D.8060007@cs.ucla.edu> 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> <87fwgnp672.fsf@rho.meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1323888732 19826 80.91.229.12 (14 Dec 2011 18:52:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2011 18:52:12 +0000 (UTC) Cc: Emacs development discussions To: Jim Meyering Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 14 19:52:08 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 1Ratvw-0000eU-6P for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 19:52:04 +0100 Original-Received: from localhost ([::1]:59628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ratvv-0003Nl-MO for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 13:52:03 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:58388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ratvt-0003Ly-4L for emacs-devel@gnu.org; Wed, 14 Dec 2011 13:52:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ratvr-0008HA-UA for emacs-devel@gnu.org; Wed, 14 Dec 2011 13:52:01 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:43123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ratvr-0008H2-Oy for emacs-devel@gnu.org; Wed, 14 Dec 2011 13:51:59 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C1B9639E800B; Wed, 14 Dec 2011 10:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmy05SQgyvNt; Wed, 14 Dec 2011 10:51:58 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4DB1C39E800A; Wed, 14 Dec 2011 10:51:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 In-Reply-To: <87fwgnp672.fsf@rho.meyering.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:146712 Archived-At: On 12/14/11 06:40, Jim Meyering wrote: > 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. Yes, but then my reward for trying to be safer and using an ACL is that my file's contents are more likely to get lost. Ouch. Plus, it's not as simple as looking for an ACL on the original file. One must also look for ACLs that might be inherited by the newly created copy. > 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 I'm afraid it's not as simple as that. Not only must the parent directory be setuid, but the file system needs to be mounted with the suiddir option. Not all file systems support that option; some silently ignore it. And won't we have a problem there with network file systems? It's not clear to me whether the setuid semantics are specified by the client OS or the server OS. (Likewise for ACLs inherited by the new file.) All in all, I think that in the long run it'll be simpler and more reliable if we create the temp file and then check that it has (or make it have) the correct ownership and permissions.