GNU bug report logs - #21538
nndoc of bad gz prevents gnus starting

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
To: submit <at> debbugs.gnu.org
Subject: nndoc of bad gz prevents gnus starting
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.

Previous Next

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