GNU bug report logs - #18141
24.4.50; saving .gz file breaks file coding

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: rgm <at> gnu.org, 18141 <at> debbugs.gnu.org, yamaoka <at> jpl.org
Subject: bug#18141: 24.4.50; saving .gz file breaks file coding
Date: Wed, 06 Aug 2014 22:45:22 +0300

> Date: Wed, 6 Aug 2014 21:08:25 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: rgm <at> gnu.org, 18141 <at> debbugs.gnu.org, yamaoka <at> 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.

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

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

> Ctrl-C in the terminal is the fastest way to do that.

I don't see why the speed is relevant here.

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

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

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.

> > > 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.  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.  After r111638, the
prompt is issued before backing up the file.  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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.