[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [leafnode-list] locking, again



Hello,

Cornelius Krasel wrote:
> 
> When musing about the subject of having a global lock (something that
> has been discussed on this list before and is not implemented very
> well in the current 2.0 beta), it occurred to me that the nntpd may
> not have to write a new groupinfo file when adding an article.
> 
> Why?
> 
> The groupinfo file contains numbers for the first and last article in
> a newsgroup. These numbers are verified by texpire and fetchnews and
> are needed by fetchnews and the nntpd. fetchnews needs to know the
> last number of an article when it sorts new articles into the spool
> to rise the article number properly. The nntpd needs to know the last
> number to give proper replies to GROUP commands.
> 
> If the nntpd would not write the groupinfo file, it would still know
> the last number because it stores it internally. This leaves the
> problem with fetchnews.
> 
> fetchnews contains a small hack to correct for small misadjustments of

not only for "small misadjustments" :-)

> the last number. If an article with the number that fetchnews thinks
> is the first new one already exists, fetchnews will notice that and
> increase the article number by one. That is, if fetchnews thinks the
> last article is e.g. 368 but if articles 354 to 372 exist on your
> HD, then fetchnews will check whether it can store the new article
> as 369, then register that the article already exists, then do the
> same for numbers 370 to 372 and finally store the new article as
> 373. However, this mechanism will not work if there are gaps in the
> numbering, e.g. if files 368, 369 and 372 exist. In that case, the
> article will be stored as 370 and a newsreader will most likely never
> see it.

I explained this behaviour in my post from June 1 2000.
"Annoying bug - was:1.9.11: article numbers (for some groups) have been"

B.T.W. I have a simple question: 
The bug concerning the firt/last article markers reset is corrected in 2.x.
(timeout_long expiration case).
My question is:
Why this is not also corrected in the last 1.9.x version ? 

I recall you that problems raised in the recent thread:
"How often should I run texpire?" are directly linked to this bug !

Greetings

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list