From: SMTP%"lane@duphy4.drexel.edu" 2-DEC-1994 11:39:07.60 To: EVERHART CC: Subj: Re: Problems converting news.items Message-Id: <9412020758.AA02252@uu7.psi.com> Date: Thu, 1 Dec 1994 14:08:59 -0400 Reply-To: Charles Lane Sender: ANU-NEWS Discussion From: Charles Lane Organization: Drexel University Physics Subject: Re: Problems converting news.items To: Multiple recipients of list ANU-NEWS In a previous post, I mentioned how a corrupted NEWS.ITEMS file would hang up my nntp feed, but with a modified NNTP_TCPWINMULTINET my feed is working again, although I get errors in ADD FILE processing. This prompted me to search through my NEWS_ADD log files looking for RMS errors....lo and behold, but I found one PRIOR to when the NEWS.ITEMS corruption hung up my nntp feed. RMS was complaining about a bad RAB/FAB data block. Well, it turns out there's a BUG (gasp! :) in NEWSUTILITY.C, routine do_new_item: /*==============excerpt from NEWSUTILITY.C, ~line 1036 ================*/ if (sys_get_nornf(&itmrab)) { /* #3 glass@vixvax.mgi.com */ if (!newsitm.itm_cachedate) { time((time_t *) &newsitm.itm_cachedate); sys_update(&newsitm); savitm.itm_num = newsitm.itm_num; newsitm = savitm; } else { /*==============end excerpt from NEWSUTILITY.C=======================*/ of course, the sys_update should be: if (sys_get_nornf(&itmrab)) { /* #3 glass@vixvax.mgi.com */ if (!newsitm.itm_cachedate) { time((time_t *) &newsitm.itm_cachedate); sys_update(&itmrab); /* <<<<<- fixed now */ savitm.itm_num = newsitm.itm_num; newsitm = savitm; } else { This bug should only get exercised when a "supercedes" article comes in, and the original article doesn't have a valid cache date (skimmed away?). It makes me wonder if sometimes the contents of the "newsitm" structure managed to fake a RAB well enough that RMS did a wacky update operation on my NEWS.ITEMS file...