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

[Vincent Lefevre]

On 2014-08-06 22:45:22 +0300, Eli Zaretskii wrote:
> > Date: Wed, 6 Aug 2014 21:08:25 +0200
> > From: Vincent Lefevre <vincent@vinc17.net>
> > Cc: rgm@gnu.org, 18141@debbugs.gnu.org, yamaoka@jpl.org
> > 
> > On 2014-08-06 20:32:27 +0300, Eli Zaretskii wrote:
> > > > (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.
> > 
> > Things may have been fixed. I don't remember exactly. There's also
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13505 that was fixed
> > not so long ago.
> 
> So I think you are talking about a problem that largely doesn't exist,
> perhaps at all.

It still exists on a file containing the \x80 byte (which happens
to be the simplest HTML file containing the Euro symbol, BTW).

> > > > 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.
> > 
> > Ctrl-C is standard to interrupt a foreground process. If the process
> > can't handle that, it should trap SIGINT. Ditto for SIGQUIT. But
> > processes must handle SIGHUP and SIGTERM gracefully, ditto for various
> > errors, like an X server crash.
> 
> Be that as it may, it is still unjustified to use such drastic
> measures where safer ones are available.

Ctrl-C is safe with any correctly written software.

> > > 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?
> > 
> > I haven't see any better way. My goal is to quit Emacs, discarding any
> > change.
> 
> My point is that you can easily discard changes without quitting
> Emacs.  If you do, the problem you raised would not have existed.

No, that's not easy: one needs to type C-g, then C-x C-c, then
answer 'n' (or 'q'), then answer 'yes', thus 10 keys instead of 2
(and also some messages to read).

> > Ctrl-C in the terminal is the fastest way to do that.
> 
> I don't see why the speed is relevant here.

It's more than 5 times as fast, thus very relevant.

> > > > 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?
> > 
> > By me. I sometimes get rid of all the backup files because I don't need
> > them, since the original file should have been kept.
> 
> Again, then don't do that.  Disk space is cheap nowadays, whereas data
> in our files is precious.

I'm tired of this stupid argument! First it is completely wrong.
Disk space is *not* always cheap. I have an account where the
default quota is 10 GB and my backup files currently take 169 MB;
this is not entirely negligible (1.7%). On a different machine,
1 GB costs 0.10 EUR per month, and I don't want to waste several
dozens of GB of backups (easily produced without clean-up). Once
becoming useless, backup files have no value.

There are other issues with backup files: if one has many files,
this makes filename completion work much less efficiently if old
files are on the way. There are also potential security/privacy
issues, in case the machine gets compromised. It's always better
not to keep obsolete files with private data.

> > A backup file is overwritten if I edit a file of the same name in
> > another directory
> 
> ??? Then your make-backup-file function (or whatever other method you
> use to put backup files in a special directory) needs to be improved,
> so that files in different directories don't overwrite each other's
> backups.

I repeat that this is normally fine for me. If a different method
were used to avoid such collisions, this means that it would be
slower to enter the filenames, even with the help of completion
(see above) or whatever.

> Really this sounds more and more like a series of problems with your
> personal configuration and setup, which is unlikely to be seen on
> someone else's machine.  I see no reason to make non-trivial changes
> to Emacs due problems that might not be rare with your peculiar setup,
> but are otherwise quite unlikely.

There is a good reason: Emacs is obviously buggy, and it's entirely
its fault.

> > > > But why isn't the backup done just before the file is actually
> > > > written?
> > > 
> > > It _is_ done "just before", see basic-save-buffer-2.
> > 
> > No, not without r111638: the backup is done before the user is asked
> > to the provide an encoding, thus not just before the file is written.
> 
> Please see the code, which speaks for itself.

What's important is what the user can see, not the code.

> basic-save-buffer-2
> calls backup-buffer and after that calls write-region, which writes
> the new contents.  Before r111638, the prompt to select a suitable
> encoding was issued from inside write-region.

So, one has:

1. The backup is made.
2. The prompt appears.
3. If the user has not killed Emacs due to this interaction, the file
   is written.

So, the backup isn't done just before the file is written.

> After r111638, the prompt is issued before backing up the file.

And that's a much more logical sequence.

> That's all the difference introduced by r111638. There's still a
> window of opportunity between backing up and writing the new
> contents; if Emacs is killed during that window, you get your
> disappearing file again.

I don't understand why the user would kill Emacs here: the user has
confirmed the save operation (no more prompts), and he can easily
see when the save has been completed.

> IOW, the window didn;t disappear, it just got smaller in those rare
> cases where Emacs needs to ask the user about encoding.

Wrong, it didn't get just smaller: it suppressed user interaction
between the backup and the write operation. That's the main point.

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