bug#13522: 24.2; save-buffer removes edited file under some conditions

[Vincent Lefevre]

On 2022-03-14 16:05:43 +0200, Eli Zaretskii wrote:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: vincent@vinc17.net,  13522@debbugs.gnu.org
> > Date: Mon, 14 Mar 2022 14:43:14 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > Is it "C-c to kill Emacs" as in "terminate Emacs with a fatal signal",
> > > or is it "C-x C-c" as in "exit Emacs in an orderly fashion"?
> > >
> > > If the former, then in general killing a program when it is in the
> > > middle of writing files isn't guaranteed to preserve those files.
> > 
> > It's the former (sort of).
> > 
> > And, yes, we make no guarantees, but the present situation doesn't seem
> > optimal.  The user may well hit `C-z' at the prompt and wonder where the
> > file disappeared to.
> 
> That's in the "if it hurts, don't do that" department, IMO.

This is silly. Ctrl-C is *standard* to interrupt commands. When there
is a risk to lose data or to get in an inconsistent state, commands
should trap SIGINT (either to ignore it or to do some cleanup before
exiting).

Note that in any case, C-x C-c in Emacs does not replace Ctrl-C in the
terminal, as with C-x C-c, Emacs quits with a zero exit status, which
may not be what one wants. Example: in a "svn ci", one may want to
abort the commit without losing the text written in Emacs. Ctrl-C in
the terminal (where "svn ci" has been run) allows one to do that.

In this bug, the issue is actually more important: When one does
C-x C-s, the file has been renamed, which is bad, because the user
may not choose what to do immediately, and many things can happen
in the period, such as a power outage, a network outage, a crash of
the machine, etc. The user may not notice the issue with the file
immediately, so that he may lose the contents (or the changes, e.g.
if the file is handled by a VCS). The file may also be needed by
other software while the user is editing it (for instance, as backup
software, or some application if this is a configuration file).

> SIGINT is a fatal signal, and our response to fatal signals cannot
> be too fancy. We just auto-save what we can and commit suicide. Even
> that is disliked by some, who say we cannot safely do anything
> non-trivial from a fatal signal handler -- and they are absolutely
> right, we do stuff that invokes undefined behavior.

SIGINT could be equivalent to something like C-g in Emacs + quit
without saving (a backup of the current buffer can be kept),
exiting with a non-zero exit status. Note that you do not need to
do everything in the signal handler. In general, what is done is
just to set some variable saying that SIGINT has been received.
The abort of the operations is done in the main code.

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