From: Eli Zaretskii <eliz@gnu.org>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: 71074@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 [thread overview]
Message-ID: <86ed9u6ksb.fsf@gnu.org> (raw)
In-Reply-To: <20240522110818.GU2665@qaa.vinc17.org> (message from Vincent Lefevre on Wed, 22 May 2024 13:08:18 +0200)
> 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.
> > 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.
next prev parent reply other threads:[~2024-05-22 13:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 1:07 bug#71074: 29.3; When doing a backup, the file is missing during interactive questions Vincent Lefevre
2024-05-20 11:30 ` Eli Zaretskii
2024-05-21 8:44 ` Vincent Lefevre
2024-05-21 12:12 ` Eli Zaretskii
2024-05-21 12:42 ` Eli Zaretskii
2024-05-22 11:08 ` Vincent Lefevre
2024-05-22 13:25 ` Eli Zaretskii [this message]
2024-05-23 14:50 ` Vincent Lefevre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ed9u6ksb.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71074@debbugs.gnu.org \
--cc=vincent@vinc17.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).