GNU bug report logs - #71074
29.3; When doing a backup, the file is missing during interactive questions

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 71074 <at> debbugs.gnu.org
Subject: bug#71074: 29.3; When doing a backup, the file is missing during interactive questions
Date: Wed, 22 May 2024 16:25:24 +0300

> Date: Wed, 22 May 2024 13:08:18 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 71074 <at> 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.

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.