dave@boingo.med.jhu.edu (David Heath) (02/21/90)
We run nn 6.3.10. Several newsgroups consistently report errors in the log file and are unreadable by nn. I believe that this is because they have no .x and .d files. Nnadmin reports database inconsistency on these groups and attempts to renumber them. What is the best way to fix this problem? I have tried Recollecting these groups, with no success. Can I just create empty .x and .d files for these newsgroups? Here is a sample from the log file: X: Feb 20 20:13 (M): group comp.lang.asm370 renumbered X: Feb 20 20:13 (M): group comp.sys.zenith.z100 renumbered X: Feb 20 20:13 (M): group comp.terminals.tty5620 renumbered C: Feb 20 20:13 (M): Collect: 27 art, 23 gr, 14 s V: Feb 20 21:52 (dave): Database inconsistency in group comp.terminals.tty5620 V: Feb 20 21:52 (dave): Database inconsistency in group comp.sys.zenith.z100 V: Feb 20 21:53 (dave): Database inconsistency in group comp.lang.asm370 Any help would be appreciated! ----------------------------------------------------------------------------- Dave Heath dave@boingo.med.jhu.edu "``Bang'' goes another Kanga on the bonnet of the van"
storm@texas.dk (Kim F. Storm) (02/22/90)
dave@boingo.med.jhu.edu (David Heath) writes: >We run nn 6.3.10. Several newsgroups consistently report errors >in the log file and are unreadable by nn. I believe that this is >because they have no .x and .d files. Nnadmin reports database >inconsistency on these groups and attempts to renumber them. >X: Feb 20 20:13 (M): group comp.lang.asm370 renumbered Normally, there will be no .x (index) and .d (data) files for empty groups, so it is ok for some groups not to have these files. But it is certainly not correct if non-empty groups don't have these files. The occurrance of the "renumbering" certainly looks interesting, since this is the first time I have seen the "renumbered" code being used. Let me try to explain what renumbering means: When new articles arrives to the system, inews/rnews will look at the active file to get a number for the new article, and increase the "last article" number in the active file by one. When "expire" is run to clean out old news articles, it will update the "first article" number in the active file to reflect the current first article. nnmaster keeps track of both the "first article" and "last article" in the active file and compares these to the corresponding numbers for the articles stored in the database. Normally, we can expect that the "first" and "last" values will never be decreased, since it is not safe to reuse old article numbers (since these are already marked as read in the users .newsrc files). Anyway, nnmaster keeps an eye on these two values, and if it ever sees one of the them decrease, it will assume that somebody "reinitialized" the group (for whatever reason). This is reported as "group ... renumbered" in the log file. And as I said above, I have never actually seen this code "in action". I think it may also happen if the "first" article number "is out of range", i.e. larger than "last+1" or maybe 0. But really this situation "cannot happen", so, it has been disabled in release 6.4. BUT IF ANYBODY ELSE HAS SEEN THIS HAPPEN, TELL ME! >What is the best way to fix this problem? I have tried Recollecting >these groups, with no success. I suggest you take a good look at the active file for these groups. You can use nnadmin to get a look at what nnmaster thinks the information is (G) (group.name) (H). That might help you. It will also show some data and index offsets; these should be zero if there are no .x and .d files. >Can I just create empty .x and .d files for these newsgroups? No that will certainly not work! -- Kim F. Storm storm@texas.dk Tel +45 429 174 00 Texas Instruments, Marielundvej 46E, DK-2730 Herlev, Denmark No news is good news, but nn is better!