From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonathan Tomer Newsgroups: gmane.emacs.bugs Subject: bug#35497: [PATCH] Don't rewrite buffer contents after saving by rename Date: Tue, 30 Apr 2019 12:27:55 -0700 Message-ID: References: <20190429232009.94549-1-jktomer@google.com> <87pnp4t0zp.fsf@gmx.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007e34480587c46665" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="208345"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35497@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 30 21:32:29 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLYUO-000s34-QJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2019 21:32:29 +0200 Original-Received: from localhost ([127.0.0.1]:52293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLYUN-000176-RO for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Apr 2019 15:32:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLYR6-0006tL-El for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 15:29:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLYR4-0007Fb-ME for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 15:29:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57106) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hLYR4-0007FO-GY for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 15:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hLYR4-0001gB-4u for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 15:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonathan Tomer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Apr 2019 19:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35497 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35497-submit@debbugs.gnu.org id=B35497.15566524946399 (code B ref 35497); Tue, 30 Apr 2019 19:29:02 +0000 Original-Received: (at 35497) by debbugs.gnu.org; 30 Apr 2019 19:28:14 +0000 Original-Received: from localhost ([127.0.0.1]:42417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLYQH-0001f8-Rk for submit@debbugs.gnu.org; Tue, 30 Apr 2019 15:28:14 -0400 Original-Received: from mail-ua1-f42.google.com ([209.85.222.42]:35797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLYQG-0001ev-DX for 35497@debbugs.gnu.org; Tue, 30 Apr 2019 15:28:13 -0400 Original-Received: by mail-ua1-f42.google.com with SMTP id g16so2494814uad.2 for <35497@debbugs.gnu.org>; Tue, 30 Apr 2019 12:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FVMi2aTH2JTTbUdJDoj5Zz0YL9XfqkkZs7jmegfZiBA=; b=N48qLt2hxCGXbj4s20WpwUxMIagiSfjzgYVWJHFgSewHoTDa/uNFDAQ3DgVpWhvZl2 A/cF2zKfPpVzmGhLElO4wKwmlbJLT4Y6wHHWk3HXhsLL//+8bj/HBi5DtqO8vwDP8aEo UBSHieiORhCFeDZJLNw5YBuvYd/yhgzt1/jRUpgpH8dNSLG+gMfTciUo1RaN2RUFnBbY eki3elqC16myRwrVHEN1l9sXSTmkl5j+SjhJrirXEyfoCn7aqzutvFVB5etM99m2GIAU bImbkuEwmSyeZnFyiPVuPwVf7akyX4se8FF46SThCwNfRZqC9mdM4u0hiR8XniJDzPiv Ybzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FVMi2aTH2JTTbUdJDoj5Zz0YL9XfqkkZs7jmegfZiBA=; b=kYqmyOyU5szcCs37YopeRU08qYFT4GYBOoVjZx16e/dXr1nbIR/zsgg5+M0TIPG97A WQrvEWYmqbxa9gsqdZkg512xE17hW2paK5MRuEUDYNUKz6axQ4i79QFwDslWDB8+f1DD 6TdtlAxfuc2z6CKOz1Cc7LPb5bFGXvVN6dAoRt+c9f6Lr+rnCHAi/bn5AVtcd3s22wP2 EMg+oztu4WpD7lsN8id4uwAC21QtWfGlwwKtfoVPIb+S4t4EH8FneJjeENTZ9UXgDOeZ 9hway/Ef/ADlkBrejgeo/YKYRbo1vCEyYROrBXvwMQp+uyf5TyyHJ+JBZifmoMuqZ696 e6nQ== X-Gm-Message-State: APjAAAX7IKuvDy60LsVEJR9JHzFI3Svi2GPg1qte4hJfLpXPIRSHG4oQ lCoqWh9OC7E+5UdpXtyNnbNiwH6WSSjuvnBxqCNs0w== X-Google-Smtp-Source: APXvYqz8qXiDpOwVzy5A29mn71ieXU3vVmIDu5367LYruqgu50Db5I+IH+f0NIhyiB9vk/0NimXxOviEEpRJ5TQrOGI= X-Received: by 2002:ab0:25cc:: with SMTP id y12mr1887035uan.113.1556652486402; Tue, 30 Apr 2019 12:28:06 -0700 (PDT) In-Reply-To: <87pnp4t0zp.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158530 Archived-At: --0000000000007e34480587c46665 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 30, 2019 at 12:18 AM Michael Albinus wrote: > Jonathan Tomer writes: > > Hi Jonathan, > > Thanks for the patch. > > > --- a/etc/NEWS > > +++ b/etc/NEWS > > @@ -340,6 +340,13 @@ longer. > > ** Multicolor fonts such as "Noto Color Emoji" can be displayed on > > Emacs configured with Cairo drawing and linked with cairo >= 1.16.0. > > > > +--- > > +** The file-precious-flag is now respected correctly. > > +A bug previously caused files to be saved twice when > > +`file-precious-flag' or `break-hardlinks-on-save' were specified: once > > +by renaming a temporary file to the destination name, and then again > > +by truncating and rewriting the file, which is exactly what > > +`file-precious-flag' is supposed to avoid. > > > > * Editing Changes in Emacs 27.1 > > We don't describe bug fixes in etc/NEWS. > Thanks, I'll fix. What's the preferred mechanism for sending an updated patch -- send an entirely new patch (relative to upstream) on a new thread, or on this thread, or a delta to apply as an additional commit on top of my previous patch? > +(ert-deftest files-tests-dont-rewrite-precious-files () > > + "Test that `file-precious-flag' forces files to be saved by > > +renaming only, rather than modified in-place." > > I haven't checked the situation with Tramp. It cares also for > file-precious-flag, bug I don't remember whether it behaves as strict as > you have tested here. Do you want to write a Tramp test for this? It > would fit into tramp-tests.el. > The actual implementation of file-precious-flag's behavior is entirely handled by basic-save-buffer-2 -- TRAMP substitutes different implementations for write-region and rename-file but the decision of which to use comes from outside. The only feature TRAMP adds is that, when file-precious-flag is set, the local and remote temp files are checksummed and the write is considered to have failed if they differ (preventing the final rename into place). I suppose the reason this is done only when file-precious-flag is set is that in the normal case it's too late to do anything about an error. In other words, I don't believe TRAMP is able to change the strictness of file-precious-flag, unless its implementation of rename-file ends up being nonatomic (which is likely the case for some remotes, but in that case an atomic write is probably impossible anyway). That said, I'm happy to add a test to tramp-tests.el as well; at the very least, with the mock tramp method we should see that the destination file is renamed-to rather than overwritten as well. Best regards, Michael. > Thanks for the fast review! --0000000000007e34480587c46665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 30, 2019 at 12:18 AM Michael = Albinus <michael.albinus@gmx.de> wr= ote:
Jonathan Tomer <jktomer@google.com> writes:

Hi Jonathan,

Thanks for the patch.

> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -340,6 +340,13 @@ longer.
>=C2=A0 ** Multicolor fonts such as "Noto Color Emoji" can be = displayed on
>=C2=A0 Emacs configured with Cairo drawing and linked with cairo >= =3D 1.16.0.
>
> +---
> +** The file-precious-flag is now respected correctly.
> +A bug previously caused files to be saved twice when
> +`file-precious-flag' or `break-hardlinks-on-save' were specif= ied: once
> +by renaming a temporary file to the destination name, and then again<= br> > +by truncating and rewriting the file, which is exactly what
> +`file-precious-flag' is supposed to avoid.
>=C2=A0
>=C2=A0 * Editing Changes in Emacs 27.1

We don't describe bug fixes in etc/NEWS.

Thanks, I'll fix. What's the preferred mechanism for sending = an updated patch -- send an entirely new patch (relative to upstream) on a = new thread, or on this thread, or a delta to apply as an additional commit = on top of my previous patch?

> +(ert-deftest files-tests-dont-rewrite-preciou= s-files ()
> +=C2=A0 "Test that `file-precious-flag' forces files to be sa= ved by
> +renaming only, rather than modified in-place."

I haven't checked the situation with Tramp. It cares also for
file-precious-flag, bug I don't remember whether it behaves as strict a= s
you have tested here. Do you want to write a Tramp test for this? It
would fit into tramp-tests.el.

The actu= al implementation of file-precious-flag's behavior is entirely handled = by basic-save-buffer-2 -- TRAMP substitutes different implementations for w= rite-region and rename-file but the decision of which to use comes from out= side. The only feature TRAMP adds is that, when file-precious-flag is set, = the local and remote temp files are checksummed and the write is considered= to have failed if they differ (preventing the final rename into place). I = suppose the reason this is done only when file-precious-flag is set is that= in the normal case it's too late to do anything about an error.
<= div>
In other words, I don't believe TRAMP is able to cha= nge the strictness of file-precious-flag, unless its implementation of rena= me-file ends up being nonatomic (which is likely the case for some remotes,= but in that case an atomic write is probably impossible anyway). That said= , I'm happy to add a test to tramp-tests.el as well; at the very least,= with the mock tramp method we should see that the destination file is rena= med-to rather than overwritten as well.

Best regards, Michael.
<= div>
Thanks for the fast review!
--0000000000007e34480587c46665--