home *** CD-ROM | disk | FTP | other *** search
- From: grant@bluemoon.uucp (Grant DeLorean)
- Newsgroups: alt.sources
- Subject: Re: unbatcher out of sync?
- Message-ID: <1991Feb19.163942.26030@bluemoon.uucp>
- Date: 19 Feb 91 16:39:42 GMT
-
- em@dce.ie (Eamonn McManus) writes:
-
- >henry@zoo.toronto.edu (Henry Spencer) writes:
- >>It means "something's wrong with your batch": relaynews did not find a
- >>"#! rnews nnnnn" line where one should have been. Typically this means
- >>garbling during preparation or transmission. One notorious trouble spot
- >>is that the batch format cannot tolerate transformations of newlines to
- >>CR-LF pairs; the byte counts in the "#! rnews" lines must be spot-on.
-
- >We had `unbatcher out of sync' problems at a site I was involved in, which
- >was fed its news by mail from a VMS site (ugh). The VMS mailer (PMDF) got
- >confused when lines exceeded 256 characters, as References lines often do,
- >and would make a total hash of the header when this happened. As a result,
- >the "#! rnews" count would always be off by a small amount for the affected
- >article. C News resyncs at the next "#! rnews" line, but if the count is
- >too long for the actual article contents it will have missed the start of
- >the article following the garbled one.
-
- The other way that relaynews can get out of sync is if there are two
- or three spaces between "#! rnews" and the number. I know at least
- ufgate's batcher does this (who cares, right?). The simple solution
- to this one is to have relaynews look again to find the number with
- the string length incremented by 1 (doing it again with the string length
- 2 longer than originally intended doesn't seem like a bad idea).
- --
- Grant DeLorean (grant@bluemoon) {n8emr|nstar}!bluemoon!grant
-