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

[Vincent Lefevre <vincent@vinc17.net>]

On 2024-05-22 16:25:24 +0300, Eli Zaretskii wrote:
> > Date: Wed, 22 May 2024 13:08:18 +0200
> > From: Vincent Lefevre <vincent@vinc17.net>
> > 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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)