bug#71074: 29.3; When doing a backup, the file is missing during interactive questions

[Eli Zaretskii]

> Date: Tue, 21 May 2024 10:44:16 +0200
> From: Vincent Lefevre <vincent@vinc17.net>
> 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?

> Whether renaming or copying, the backup should be done just before
> actually saving.

We already do that.  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.

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.  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.

So I don't see how we could significantly change this situation
without losing very useful features, and therefore I think
backup-by-copying is the best solution we can provide in such cases.