🚀 go-pugleaf

In article <20050107.0218.58980snz@dsl.co.uk>
           bhk@dsl.co.uk "Brian {Hamilton Kelly}" writes:

> On Thursday, in article <crjjkt$1bp$1@gate.mcsquawk.org.uk>
>      william@mcsquawk.org.uk "William F. McCaw" wrote:
[..]
> >    I pulled the article down from news.dcu and used Ethereal to capture &
> > examine the packets, and I saw exactly what you're reporting, header lines
> > terminate with CR-LF, body lines with just LF, then normal service resumes
> > with the article terminator...
> 
> [snip]
> 
> Thanks for the confirmation.
> 
> >    I also checked the article from the server I normally use these days
> > (news.gradwell.net) and that came down normally with CR-LF line endings
> > throughout.
> 
> Thanks too for that: it seems that, as I first suspected, news.dcu alone
> is serving up corrupted copies of that particular article.

I wonder if this is what I'm seeing here (the symptoms, anyway)?  
After posting last week about a possible 127/128 bug in Gremnos/ 
unbatch/WHY I had exactly the same thing happen during a news 
unbatch last Friday (that of the "#! rnews ..." being missed and 
running into the next article).  Coincidentally, it was again the 
"Subject: WINDOWS USERS: your questions answered" article that 
got tacked on to the end of the previous article, but this time 
to an article in comp.security.misc.

This time there were _definitely_ no NUL bytes reported (using 
correct versions of Gremnos) and I also kept a copy of the 
incoming batch.txt[1].  Everything in the latter looked fine 
except for the article length reported in the "#! rnews ..." 
line, which was about 30 bytes out from what I counted.  Now 
unbatch makes a correction for each line after removing the '\r' 
assumed in each input line when calculating the article length 
for checking the start of the next batch article, so if it is 
subtracting 1 for lines that do not have a '\r' I can see where 
it might not find the start of the next article within its 
[programmed] 10 byte tolerance.

[1] sadly, not the original; the incoming batch.txt is passed 
first to PEEL to strip hdr-only articles, which program removes 
any EOL chars in each line and replaces them with CRLF as it 
processes the file :-(

> Back to Mr Clayton, I believe; I note that he's been very quiet since I
> moved this thread to this froup: perhaps that's *why* he suggested it :-)

It would be nice to hear back that the newsfeed has been fixed 
but in the meantime I'll be unbatching with '-l' to ignore 
article length checking and seeing if that makes my problem go 
away.

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."