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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: vincent@vinc17.net,  13522@debbugs.gnu.org
> Date: Tue, 15 Mar 2022 12:42:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.  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.
> 
> I agree that killing Emacs is unusual.  But suspending Emacs (with
> `C-z') is something people do all the time, and in this case, if the
> user is suspending Emacs on this prompt, they might be doing that to
> examine the file before saving it, for instance.  And then they'll be
> confused that it's apparently gone.

Does the problem actually happen if you type C-z?  Emacs is not dead
in that case, just suspended.  Type "fg RET", and you are back inside
Emacs, and can pick up where you left off.  Right?

> So I think we should fix this, perhaps the way Glenn suggested in his
> patch, but it's obviously not high priority.

I'm not against making this particular scenario have a smaller window
of opportunity (if the solution is clean), but it will still be
possible to cause similar problems by using SIGINT or any other signal
during this and other similar procedures that aren't atomic.