reid@Glacier.ARPA (Brian Reid) (09/16/85)
Robert Elz posted to net.news.b an article saying that the article-eater bug is not real, and that he is unable to duplicate the problem. His article never arrived at Glacier, having been eaten by the article-eater bug somewhere along the way. I love it! Luckily, he mailed me a copy of the article so I know what he said. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
kre@munnari.OZ (Robert Elz) (09/18/85)
In article <11854@Glacier.ARPA>, reid@Glacier.ARPA (Brian Reid) writes: > Robert Elz posted to net.news.b an article saying that the article-eater bug > is not real, and that he is unable to duplicate the problem. His article > never arrived at Glacier, having been eaten by the article-eater bug > somewhere along the way. I love it! Luckily, he mailed me a copy of the > article so I know what he said. Well, I didn't say that the bug doesn't exist, I just said that I hadn't been able to make it happen. I asked Brian (or Chuq) to send me something so that I could see it myself. I have asked Brian again since. I still have yet to see it. Just to confuse the issue, my previous article - the one Brian refers to (<906@munnari.OZ>) arrived safely at decvax. Decvax forwards news to decwrl. Brian told me that that item never made it to decwrl. This is where it gets interesting - the decvax -> decwrl link does NOT use the batching code that apparently has this bug in it, it uses Piet Beertema's (mcvax!piet) version. That is similar in action, but not the same (certainly the code is different). So, given that my article didn't make it to decwrl (nor to glacier, who get news from decwrl), it wasn't the problem that has been (occasionally) discussed here that did it! Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov
bukys@rochester.UUCP (Liudvikas Bukys) (09/20/85)
In case anyone's still thinking about finding this bug: some suggestions. I was one of the first to claim that it wasn't really a problem. This was BECAUSE a "problem" which is not really a problem was described as the source of the black hole. Namely, it was claimed that it was bad for news batches to contain "#! rnews" not at the beginning of the line. This is not really a problem, as I demonstrated to myself by making some articles without newlines at the end, batching and unbatching them. Furthermore, the 2.10.2 unbatcher is SO simple, it is hard to imagine how it is going wrong. It therefore seems likely to me that the input to the unbatcher is getting munged. It is very suspicious that this is triggered by articles containing a 0xFF byte. - make sure that compress on your machine can handle 0xFF bytes. - make sure that your stdio library doesn't sign-extend that character when you getchar() or getc() it. - make sure your news paths can transmit everything you send over them, all eight bits if necessary. Finally, don't claim to have "found the problem" unless you accompany that report with sample articles, and instructions for duplicating the problem, right down to putting it into rnews and having it disappear.