From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vincent Lefevre Newsgroups: gmane.emacs.bugs Subject: bug#71074: 29.3; When doing a backup, the file is missing during interactive questions Date: Wed, 22 May 2024 13:08:18 +0200 Message-ID: <20240522110818.GU2665@qaa.vinc17.org> References: <20240520010748.GB323381@qaa.vinc17.org> <86pltgaff3.fsf@gnu.org> <20240521084416.GH2665@qaa.vinc17.org> <86msoj8iui.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29293"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.13+76 (1f3da810) vl-167818 (2024-04-20) Cc: 71074@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 22 13:09:12 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s9jqI-0007Ky-L5 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 May 2024 13:09:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s9jq6-0000cG-Cy; Wed, 22 May 2024 07:08:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s9jq5-0000by-0w for bug-gnu-emacs@gnu.org; Wed, 22 May 2024 07:08:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s9jq4-0006S3-PQ for bug-gnu-emacs@gnu.org; Wed, 22 May 2024 07:08:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s9jqA-0004B0-EJ for bug-gnu-emacs@gnu.org; Wed, 22 May 2024 07:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 May 2024 11:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71074 X-GNU-PR-Package: emacs Original-Received: via spool by 71074-submit@debbugs.gnu.org id=B71074.171637613916048 (code B ref 71074); Wed, 22 May 2024 11:09:02 +0000 Original-Received: (at 71074) by debbugs.gnu.org; 22 May 2024 11:08:59 +0000 Original-Received: from localhost ([127.0.0.1]:55230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s9jq6-0004Am-Tw for submit@debbugs.gnu.org; Wed, 22 May 2024 07:08:59 -0400 Original-Received: from joooj.vinc17.net ([155.133.131.76]:55904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s9jq3-0004Ac-9v for 71074@debbugs.gnu.org; Wed, 22 May 2024 07:08:57 -0400 Original-Received: from smtp-qaa.vinc17.net (2a02-8428-1b1d-4d01-96a9-491d-7b48-ba31.rev.sfr.net [IPv6:2a02:8428:1b1d:4d01:96a9:491d:7b48:ba31]) by joooj.vinc17.net (Postfix) with ESMTPSA id 59D8C602; Wed, 22 May 2024 13:08:18 +0200 (CEST) Original-Received: by qaa.vinc17.org (Postfix, from userid 1000) id 1A403CA00B3; Wed, 22 May 2024 13:08:18 +0200 (CEST) Content-Disposition: inline In-Reply-To: <86msoj8iui.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:285593 Archived-At: On 2024-05-21 15:12:05 +0300, Eli Zaretskii wrote: > > Date: Tue, 21 May 2024 10:44:16 +0200 > > From: Vincent Lefevre > > Cc: 71074@debbugs.gnu.org > > > > On 2024-05-20 14:30:56 +0300, Eli Zaretskii wrote: > > > Does it help to customize the variable backup-by-copying to a non-nil > > > value? > > > > Yes, but note that a useless backup is done because the file will > > not necessarily be saved (if the save operation is canceled via > > an interactive question or due to Debian bug 1071372). > > Sure, but if the danger is to lose the file due to some calamity, a > useless backup is a very minor disadvantage, don't you agree? Yes, but this could be a future improvement. > > Whether renaming or copying, the backup should be done just before > > actually saving. > > We already do that. By "just before", I mean that there should not be any system call between a backup and the write of the file. BTW, there is actually an issue with the backup system: the backup is done only before the *first* save-buffer, while an issue might appear only for a subsequent save-buffer. > However, backup+save is not an atomic operation, and as long as it > is not atomic, there's always a window of opportunity for some > catastrophe, like a system crash or Emacs being killed, to happen > in-between. Yes, but if the window is restricted to the minimum, the probability of a system crash / killed Emacs is significantly reduced. I suppose that file-precious-flag as you suggested later may be the ultimate solution. > Moreover, Emacs being Emacs, with its high degree of customization, > some feature can customize either backup or save (or both) in a way > that makes the above-mentioned window very wide. That's what happened > in the case you reported: epa-file overrides write-contents, the Emacs > primitive that actually writes the buffer to a file, with its own > version, and that's why you get that prompt about untrusted key. So, does this mean that file-precious-flag doesn't work here? But perhaps that's a bug in epa-file, which should ensure that by default, the pathname isn't removed (due to the backup by rename) until the new file can be written. This means that it currently does the backup too early. > We cannot avoid such situations, because if we disallow customizations > like that, Emacs will no longer be Emacs. In fact, you yourself use a > similar feature, when you define find-backup-file-name to force all > the backup files to go to a specific directory. Such a function could > in theory do anything it wants, including prompting you and whatnot, > thus prolonging the window between the backup and the save. But customizations should be implemented properly to avoid issues. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)