From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/38777
Path: main.gmane.org!not-for-mail
From: Simon Josefsson <jas@extundo.com>
Newsgroups: gmane.emacs.gnus.general
Subject: Re: wrong-type-argument exiting nnml group
Date: Sat, 15 Sep 2001 21:48:18 +0200
Message-ID: <ilu8zfg9qwt.fsf@barbar.josefsson.org>
References: <87g09oz88k.fsf@harpo.homeip.net>
	<ilug09ocp4m.fsf@barbar.josefsson.org>
	<87u1y4xovs.fsf@harpo.homeip.net>
NNTP-Posting-Host: coloc-standby.netfonds.no
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1035174586 24270 80.91.224.250 (21 Oct 2002 04:29:46 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 21 Oct 2002 04:29:46 +0000 (UTC)
Cc: ding@gnus.org
Return-Path: <jas@extundo.com>
Return-Path: <jas@extundo.com>
Original-Received: (qmail 1323 invoked from network); 15 Sep 2001 19:48:22 -0000
Original-Received: from dolk.extundo.com (195.42.214.242)
  by gnus.org with SMTP; 15 Sep 2001 19:48:22 -0000
Original-Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241])
	(authenticated bits=0)
	by dolk.extundo.com (8.12.0/8.12.0) with ESMTP id f8FJmT0r015329;
	Sat, 15 Sep 2001 21:48:29 +0200
Original-To: Samuel Padgett <spadgett1@nc.rr.com>
In-Reply-To: <87u1y4xovs.fsf@harpo.homeip.net> (Samuel Padgett's message of
 "Sat, 15 Sep 2001 14:58:15 -0400")
Mail-Copies-To: nobody
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105
Original-Lines: 21
Xref: main.gmane.org gmane.emacs.gnus.general:38777
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:38777

Samuel Padgett <spadgett1@nc.rr.com> writes:

>> (Or manually inspect the .overview file to possibly find why it became
>> corrupt.)
>
> Gah.  Information for article 1 was split up over multiple lines
> instead of all on one NOV line.  Any idea how that might have
> happened?
>
> Hm.  Looking at it after nnml-generate-nov-databases, I see that there
> is a ^M after each header field for article 1.  Could this have caused
> the problem?

Yes.  I do not understand how that happens though, even if the article
in question uses CRLF the NOV parsing routine isn't fooled, at least
for me.

If you edebug `nnml-generate-nov-file', does the *nntpd* buffer
contain ^M's after the call to `nnheader-insert-file-contents'?  It
doesn't for me, and I suspect it is a feature but I'm not sure why it
happens.