bug#18141: 24.4.50; saving .gz file breaks file coding

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 6 Aug 2014 18:43:16 +0200
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: Glenn Morris <rgm@gnu.org>, 18141@debbugs.gnu.org, yamaoka@jpl.org
> 
> On 2014-08-06 17:36:00 +0300, Eli Zaretskii wrote:
> >  . Bug#13522, which these changes were trying to solve, happens when
> >    Emacs is killed by an external signal during the time between
> >    backing up the original file and writing the new one.  (This time
> >    can be quite large if write-region asks the user to choose a
> >    suitable encoding for the new content.)  That is a pretty rare
> >    situation, and IMO it's perfectly OK for Emacs to leave just the
> >    backup file if it was brutally killed during that time window.
> 
> No, this is not rare

Maybe for you, because you are used to abort Emacs by a signal.  I
never had such experiences in all the long years I'm using Emacs.

> (Emacs seems to be confused on files that have several encodings,
> such as mailboxes)

It does?  I didn't see that since Emacs 23.1 at the least.

> and I sometimes hit Ctrl-C in the terminal (from which Emacs was
> started) to discard any change.

Then don't do that, if it hurts.  C-g or M-~ or C-/ in Emacs will
discard changes (in different scenarios) without any adverse effects,
as will killing the buffer that visits the modified file.  Why
brutally abort Emacs by a signal, when Emacs gives you better ways to
do that?

> And that's not OK to only leave the backup file,
> since it can be removed or overwritten pretty quickly, before
> I notice that the original file is gone.

Removed or overwritten by whom or what?

> But why isn't the backup done just before the file is actually
> written?

It _is_ done "just before", see basic-save-buffer-2.