battan@tc.fluke.COM (Jim Battan) (02/27/88)
Each night, I have a script that effectively does an
egrep -v 'sent|received'
on the LIB/log file. And each day I notice that a large
(usually around 60) number of articles have the following
error message preceding them:
<date>: <site> linecount expected n1, got n2
where n1 is usually 1 less than n2, but not always. And
the messages are coming from a wide variety of sites, many
of them that I presume have the latest-and-greatest software
(I won't embarrass anyone by listing them). Sure enough, when
I go to look at the batch files, they do have incorrect counts
in the "lines:" header.
My question: Has anyone else noticed this, and better yet, found
out why it's happening?
I know this isn't too important, since the article gets posted okay
anyway; just call me picky. FYI: I'm running B 2.11 Patch #10.
--
Jim Battan Domain: battan@tc.fluke.COM Voice: +1 206 356 6469
UUCP: {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,sun}!fluke!battangnu@hoptoad.uucp (John Gilmore) (02/29/88)
battan@tc.fluke.COM (Jim Battan) wrote: > <date>: <site> linecount expected n1, got n2 > where n1 is usually 1 less than n2, but not always. I have been watching this for a while, off and on. Here is a message from a few months ago about it. I don't think anyone has looked at the news software to see if this is the right answer, yet... From: hoptoad!gnu (John Gilmore) Newsgroups: news.software.b Subject: Re: Missing lines from articles Message-Id: <2265@hoptoad.uucp> Date: 5 Jun 87 12:16:56 GMT In article <255@catsim.UUCP>, tony@catsim.UUCP (Tony Cratz) writes: > It also seems that it is ALWAYS one line which is > missing... I got a copy of a message back by email after it had left my machine via news paths, and noticed something funny. The messages matched exactly except that where an "Xref:" line existed on my disk, there was an extra blank line in the copy I got from the outside world. Aha! I suspect that whatever software is snuffing "Xref:" lines is not DELETING the line, but just EMPTYING it down to a newline. Since in most cases the Xref: line is the last line of the header, this just makes the message appear to be one line longer. The local news stats always show a few messages from me to ptsfa which are exactly one line longer than their Lines: header. Also, about half the sites with line length problems reported are off by a single line in all the bad articles. Now if the Xref: line was somewhere in the middle of the header...hmm... have you ever noticed those messages where half the header appears in the text of the message? Hmm! Anybody seen the spot(s) in the news software where the Xref: lines get junked? Can you look there again? -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre
larry@focsys.UUCP (Larry Williamson ) (02/29/88)
From article <2995@fluke.COM>, by battan@tc.fluke.COM (Jim Battan): > Each night, I have a script that effectively does an > egrep -v 'sent|received' > on the LIB/log file. And each day I notice that a large > (usually around 60) number of articles have the following > error message preceding them: > <date>: <site> linecount expected n1, got n2 > where n1 is usually 1 less than n2, but not always. And I get dozens of these messages in my log file every night as well. I have been ignoring them since there does not seem to be any problem. -- --- Larry Williamson Focus Automation Systems UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4 +1 519 746 4918
battan@tc.fluke.COM (Jim Battan) (03/02/88)
In article <4136@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >battan@tc.fluke.COM (Jim Battan) wrote: >> <date>: <site> linecount expected n1, got n2 >> where n1 is usually 1 less than n2, but not always. >In article <255@catsim.UUCP>, tony@catsim.UUCP (Tony Cratz) writes: >> It also seems that it is ALWAYS one line which is >> missing... >Aha! I suspect that whatever software is snuffing "Xref:" lines >is not DELETING the line, but just EMPTYING it down to a newline. >Since in most cases the Xref: line is the last line of the header, >this just makes the message appear to be one line longer. Also, about half >the sites with line length problems reported are off by a single line >in all the bad articles. I doubt this is the source of the problem. The "Lines:" header only counts the number of lines in the body of the article, after the first blank line, after all the headers. Besides, that wouldn't account for the ~20% that are off by more than 1 line. I did glance through the code, and it looks like there are two pieces of code in inews.c, explicitly labeled as kludges, that try to deal with the "article truncation problem," which I assume is the infamous "line eater". That's as far as I've gotten so far. Anyone else looking into this? -- Jim Battan Domain: battan@tc.fluke.COM Voice: +1 206 356 6469 UUCP: {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,sun}!fluke!battan