erf@progress.COM (Eric Feigenson) (02/04/91)
I've been getting messages from expire (well, just this one message, actually) that look like: expire: wrong number of fields in `<56191@eerie.acsu.Buffalo.EDU> 665179672...' What does this mean (aside from the obvious fact that there are a different number of fields than expected)? Is it serious? Will it go away on its own? Grepping the history file to find this line yields: <56191@eerie.acsu.Buffalo.EDU> 665179672~- rec.a<L18^K6*@rpi.edu> 665180849~- misc.jobs.misc/1232 (looking at this line reveals the obvious problem that a control character is stuck in the middle of the line, as if struck by something like line noise... how could this happen? How can I fix these lines???) Any help will be appreciated! Thanks in advance! -EricF -- Eric R. Feigenson UUCP: mit-eddie!progress!erf Progress Software Corp. Internet: erf@progress.com 5 Oak Park Bedford, MA 01730
erf@progress.COM (Eric Feigenson) (02/05/91)
Stupid me... in my original posting (see the references line in the header) I forgot to mention that I'm running C-news patched to the 15-Dec-90 patch. Sorry 'bout that! -EricF -- Eric R. Feigenson UUCP: mit-eddie!progress!erf Progress Software Corp. Internet: erf@progress.com 5 Oak Park Bedford, MA 01730
henry@zoo.toronto.edu (Henry Spencer) (02/05/91)
In article <1991Feb4.144836.2706@progress.com> erf@progress.COM (Eric Feigenson) writes: >I've been getting messages from expire (well, just this one message, actually) >that look like: > >expire: wrong number of fields in `<56191@eerie.acsu.Buffalo.EDU> 665179672...' > >What does this mean (aside from the obvious fact that there are a different >number of fields than expected)? Is it serious? Will it go away on its >own? ... It means that your history file is (slightly) corrupted and needs attention. In old C Newses it is quite serious, because expire will not continue when it sees this. Modern ones are a bit less paranoid and will carry on, but that line isn't going to go away without manual editing. You need to go in manually and edit that line (after locking the news system!), rebuild the index (use mkdbm or do an expire run), and then run addmissing to pick up any articles that got dropped from the history file as a result of whatever caused the original problem. Assuming nothing's gone wrong with locking etc., the main cause of something like this is a crash during news processing. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
tale@rpi.edu (David C Lawrence) (02/05/91)
In <1991Feb4.144836.2706@progress.com> erf@progress.COM (Eric Feigenson):
expire: wrong number of fields in `<56191@eerie.acsu.Buffalo.EDU> 665179672...'
What does this mean (aside from the obvious fact that there are a different
number of fields than expected)?
Um, gee. You want hidden messages? I guess the only other thing you
could say it significantly meant is that somehow your history file got
a little corrupted and expire won't be able to handle any of the
aflicted lines. In the case that you have here, that means at least
two articles, possibly more.
Is it serious? Will it go away on its own?
Depends on what you call serious. It will mean that the article(s)
that were in the lines which got clobbered will not be expired. The
line gets rewritten to the new history file so you will keep seeing it
until you deal with it manually.
<56191@eerie.acsu.Buffalo.EDU> 665179672~- rec.a<L18^K6*@rpi.edu> 665180849~- misc.jobs.misc/1232
(looking at this line reveals the obvious problem that a control character
is stuck in the middle of the line, as if struck by something like line
noise... how could this happen? How can I fix these lines???)
Well, news strips most control characters so if a troublesome one was
there, I don't know what it is. Unless maybe you are referring to ^K,
which is infact two printing characters in the real message-id.
My suggested cure is to locknews, edit history, delete that line, then
run addmissing. This will retain all of your /expired/ lines and
ensure that the two or more articles which got bitten in this
corruption will be back in the history file as long as they are still
in spool. No, I don't have any solid idea about how come the
corruption happened at all.
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))henry@zoo.toronto.edu (Henry Spencer) (02/05/91)
In article <JH%&_A#@rpi.edu> tale@rpi.edu (David C Lawrence) writes: >My suggested cure is to locknews, edit history, delete that line, then >run addmissing... One missing step: rebuild the history index using mkdbm (must rename that...) or expire. This is relatively unimportant if using dbm, but very important if using dbz -- the offsets into the history file must be right. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry