makehistory confusion

[Alex Kiernan]

Graeme Mathieson <graeme+inn-workers at mathie.cx> writes:

> I'm having some trouble convincing the server I have running inn CURRENT
> (as of 20011219) to keep track of all the articles it has on spool.
> I'll describe this from the point where I've noticed that all the old
> articles are missing.
> 
> I rebuild overview and history with:
> 
> makehistory -b -f history.n -O -e -F
> 
> then move the history files around into the correct place, restart innd
> and issue `ctlinnd renumber ''`.  All the groups I have on tradspool are
> renumbered back down to the lo article number that actually exists on
> spool.
> 
> The next time news.daily runs, overview seems to be expired for these
> articles, though they are not removed from disk.  I'm kinda confused as
> to what's going on...
> 
> I the course of trying to figure it out, I noticed that, of the million
> entries in the history file that makehistory was generating, only 4000
> of them had SM tokens attached to them.  That seems wrong, since by
> virtue of the fact that makehistory is scanning the spool, everything it
> picks up ought to have a storage token...  I tracked that down to the
> following in expire/makehistory.c (around line 700):
> 
>     if (!NoHistory) {
>         bool r;
> 
>         if (Expires > 0)
>             r = HISwrite(History, MessageID,
>                          Arrived, Posted, Expires, art->token);
>         else
>             r = HISremember(History, MessageID, Arrived);
>         if (r == false) {
>             (void)fprintf(stderr, "makehistory: Can't write history line, %s\n", strerror(errno));
>             exit(1);
>         }
>     }
> 
> Why is doing a HISwrite() conditional on there being an Expires: header?
> I'm currently rebuilding history with it unconditionally calling
> HISwrite() instead.  We'll see what happens.

Checking back over the CVS history, its a mistake from when I did the
history API work, I think you have the right fix though (which I'm
about to commit).

I just noticed I missed documenting HISremember too :-(

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC