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: Thu, 23 May 2024 16:50:02 +0200 Message-ID: <20240523145002.GA2163@cventin.lip.ens-lyon.fr> References: <20240520010748.GB323381@qaa.vinc17.org> <86pltgaff3.fsf@gnu.org> <20240521084416.GH2665@qaa.vinc17.org> <86msoj8iui.fsf@gnu.org> <20240522110818.GU2665@qaa.vinc17.org> <86ed9u6ksb.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="2625"; 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 Thu May 23 16:51:08 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 1sA9md-0000Vz-Jf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 May 2024 16:51:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sA9mU-0007A0-10; Thu, 23 May 2024 10:50: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 1sA9mR-00079L-IJ for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 10:50:55 -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 1sA9mR-0002tc-AG for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 10:50:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sA9mX-0003bt-Mk for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 10:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 May 2024 14:51:01 +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.171647581413849 (code B ref 71074); Thu, 23 May 2024 14:51:01 +0000 Original-Received: (at 71074) by debbugs.gnu.org; 23 May 2024 14:50:14 +0000 Original-Received: from localhost ([127.0.0.1]:59375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sA9lm-0003bJ-0w for submit@debbugs.gnu.org; Thu, 23 May 2024 10:50:14 -0400 Original-Received: from cventin.lip.ens-lyon.fr ([140.77.13.17]:39232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sA9li-0003bA-5z for 71074@debbugs.gnu.org; Thu, 23 May 2024 10:50:13 -0400 Original-Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.97) (envelope-from ) id 1sA9la-000000005ze-0aas; Thu, 23 May 2024 16:50:02 +0200 Content-Disposition: inline In-Reply-To: <86ed9u6ksb.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:285716 Archived-At: On 2024-05-22 16:25:24 +0300, Eli Zaretskii wrote: > > Date: Wed, 22 May 2024 13:08:18 +0200 > > From: Vincent Lefevre > > Cc: 71074@debbugs.gnu.org > > > > > > 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. > > I don't see how this could be done in Emacs, sorry. But if you or > someone has practical ideas, let's hear them. > > > 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. > > This is how backups in Emacs work. Catastrophes do happen, but at > least Emacs attempts to auto-save everything when it is about to > crash. It doesn't always work, depending on the reason for the crash. OK, this is actually what I expected to get with the gpg bug. Since the file.gpg file was not restored from the "save-buffer" failure, I expected to get a "#file.gpg#" file for recovery, but there was none. Alternatively, Emacs could have restored the file from the backup. I don't what happened, but I don't see the logic behind Emacs. For instance, when editing a normal file with the Emacs GUI and doing Ctrl-C in the terminal before saving, a recovery file is created. But nothing similar is done with .gpg file (of course, it is not possible to have the unsaved contents because encryption could not be done, but I would expect at least the saved-encrypted version back in this case, instead of neither the file nor a recovery file). > > > 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? > > AFAICT, it does work. Its purpose is to avoid overwriting the > original file until the new stuff was successfully written to disk. BTW, it leaves empty files, for instance, in case of gpg error: -rw------- 1 vlefevre vlefevre 0 2024-05-23 15:55:36 tmpSHlCS3 -rw------- 1 vlefevre vlefevre 0 2024-05-23 15:57:00 tmpf5O5RM > > > 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. > > I don't see how. E.g., if we let users and packages customize how > files are backed up, it's anyone's guess what will happen inside the > backup-buffer call and how much time will that take. What would be a > "proper implementation" that still allows such customizations? But > again, practical ideas are welcome. I think that this would be more or less equivalent to the file-precious-flag feature. I'm wondering why it is not enabled by default. It seems that the only "issue" is that this breaks the hard links. But hard links seem very rare in practice. If this is really an issue, the file-precious-flag behavior could be conditional to whether the file has hard links. And about "As a side effect, backups are necessarily made by copying.", another possibility could be proposed: a backup by a hardlink (if supported). Since the hardlink will normally be broken, this will normally give no hardlinks at the end, as expected. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)