tony@catsim.UUCP (06/02/87)
It has been pointed out to me by chandan@dgcad that there are a number
of articles where my news 'log' file records something like:
Jun 2 09:21 intelca linecount expected 12, got 13
I have been getting this type from not only intelca but also from
other sites that feed me. After looking at some of the paths for the
differents articles I have not been able to see anyone system that
might be at fault. It also seems that it is ALWAYS one line which is
missing (Thanks God for .signature that are more than 1 line long).
I have waited to see if anyone else was going to post a question about
this but as of this date I have not seen anything bring this point up.
My questions are:
1) Are others seeing this problem?
2) Is this caused by the ARPA->USENET gateway software?
3) Is this only a USENET problem?
4) What is the cause of this problem.
5) What can I do to help solve the problem?
Tony Cratz
--
"Looks like plant food to me!"
Disclaimer: The options stated here are mine and not those of my
company (they don't want them!).
UUCP: {hplabs|decwrl|oliveb|qantel|scgvaxd|amd|amdcad}!intelca!catsim!tony
Snail Mail: 4051 Burton Dr, Santa Clara, Ca. 95054
Phone: 408-980-9144mp@allegra.UUCP (06/07/87)
One way for extra lines to get into an article is for it to pass through a system on which rnews finds an illegal header line. header.c contains code that attempts to move an illegal header line, and all subsequent text, down into the body of the message. It almost always succeeds. Under 2.10.1 and possibly other 2.10 versions, a header line that does not contain a colon followed immediately by a space is considered illegal. Most linecount discrepancies I've seen have been off-by-one because of a header that ends in a line such as "Keywords:". If additional header lines follow an illegal header line, they'll be moved down into the body, too. For instance, in article <2634@sequent.UUCP>, you may get 5 lines moved down into the body, resulting in the message "linecount expected 22, got 27". |From: dahutch@sequent.UUCP (Dwight A. Hutchinson) |Newsgroups: talk.bizarre |Subject: Re: Jolt |Message-ID: <2634@sequent.UUCP> |References: <6315@dartvax.UUCP> <985@bucsb.bu.edu.UUCP> <6343@dartvax.UUCP> |Reply-To: dahutch@sequent.UUCP () |Followup-To: where ever your fingers go |Organization: Sequent Computer Systems, Beaverton, OR |Lines: 22 |Summary:well, gee.... |Expires:nah |Sender:me, I think... |Distribution:na |Keywords:Jersey Now, some unfortunate behavior sets in when rnews is reading from a pipe and encounters an illegal header line. After frmread() reads in all the (legal) header, it may attempt to do what could be called an unhfgets(). It has saved the file pointer via ftell() before reading in each header line. It may do an fseek() to jump backwards a bit if it thinks there's useful stuff - an illegal header line - to be saved for inclusion in the body of the article. Well, under 4.[23]bsd, ftell() on a pipe returns -1. fseek(fp, -1, 0) will jump to the end of the input buffer on 4.2bsd, skipping over 1000 or so characters and resulting in a ``line-eaten'' article. With 2.11, if the whole article is munched down to 0 lines it'll just be rejected. Under 4.3bsd it appears the fseek(fp, -1, 0) will not cause any repositioning at all, and the article will probably wind up missing just that one illegal header line. Has anyone fixed this? Mark Plotnick allegra!mp