bug#8792: 23.3; EasyPG: do not create empty buffers if file cannot be read

bug#8792: 23.3; EasyPG: do not create empty buffers if file cannot be read

[Roland Winkler]

If a gpg-encrypted file cannot be read for whatever reason (see,
e.g., bug#8791) one gets the error message

  File exists, but cannot be read

and just an empty buffer. This empty buffer can be dangerous because
emacs believes it is really visiting the file. Say, if this empty
buffer gets modified and saved automatically, this will just
override the original file. I suggest that EasyPG should be more
cautious here (or: provide a means to be more cautious if desired).


In GNU Emacs 23.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2011-06-02 on lukas

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_GB.utf8
  value of $LANG: en_US.ISO-8859-15
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-9-unix
  default enable-multibyte-characters: t

bug#8792: 23.3; EasyPG: do not create empty buffers if file cannot be read

[Daiki Ueno]

forcemerge 6568 8792
thanks

Roland Winkler <winkler@gnu.org> writes:

> If a gpg-encrypted file cannot be read for whatever reason (see,
> e.g., bug#8791) one gets the error message
>
>   File exists, but cannot be read

The fix has been in the trunk for quite some time.  Though I'm afraid
that the modification is not trivial, now it might be good to backport
it into emacs-23.

Regards,
-- 
Daiki Ueno

bug#8792: 23.3; EasyPG: do not create empty buffers if file cannot be read

[Roland Winkler]

On Fri Jun 3 2011 Daiki Ueno wrote:
> The fix has been in the trunk for quite some time.  Though I'm afraid
> that the modification is not trivial, now it might be good to backport
> it into emacs-23.

I see, thank you!

It's a bit unfortunate that this fix has not yet been applied to
emacs 23. Actually, some time ago I reported another bug with EasyPG
(bug#7026). I was surprised that this fix did not make it into emacs
23.3 that was shipped half a year later.

Roland