Subject: bug#21538: nndoc of bad gz prevents gnus starting

From: Kevin Ryde <[email-masked]>
Date: Wed, 23 Sep 2015 21:08:29 +1000

Gnus v5.13
GNU Emacs 24.5.1 (i586-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2015-06-29 on x86-csail-01, modified by Debian

If the gnus active groups include an nndoc of a gzipped file which is
corrupt in some way so gzip does not like it, then gnus gets an error on
startup and does not reach the Group buffer.

    touch /tmp/foo.gz        # empty file

    ~/.gnus.el containing
    (setq gnus-select-method '(nnml ""))

    M-x gnus
    G f /tmp/foo.gz          # create nndoc
    q                        # quit gnus
    M-x gnus                 # start gnus again
    =>
    Error while executing "gzip -c -q -d < /tmp/foo.gz"
    gzip: stdin: unexpected end of file

I struck this on a mirrored mailing list file which I had clobbered by a
failed re-download, leaving an empty .gz file.  Obviously the answer is
don't do that, but it'd be good if gnus could cope, especially since if
you don't get to the Group buffer it's not easy to unsubscribe the
offending bit, say.

I wonder if nndoc-possibly-change-buffer could trap errors around its
insert-file-contents.  jka-compr opens a window about the gzip problem
which would be ok, and gnus could treat the group as unselectable or
something.

Such a trap could make the file-exists-p test unnecessary too.
I usually think when reading a file that it's better to read and check
the result than try to predict it won't work.  Likewise the not
file-directory-p bit, since insert-file-contents is an error on a
directory.