inn 2.3.1: fix for "makehistory: tradspool: can't determine class: @050000000012000001B10000000000000000@: Bad article handle"
rra at stanford.edu
Tue Jun 5 15:18:18 UTC 2001
Jonathan Kamens <jik at kamens.brookline.ma.us> writes:
> I recently upgraded to 2.3.1 and switched to using the storage API
> while continuing to use a traditional spool.
> When I ran makehistory, I got a whole bunch of log messages of the
> form "makehistory: tradspool: can't determine class:
> @050000000012000001B10000000000000000@: Bad article handle".
> I did a search for this in DejaNews, and I found a lot of discussion
> about it but no actual fixes. Russ even hinted at the actual problem in
> one of his postings about it, so I was surpised to find that it hadn't
> been fixed yet.
I'm almost positive I fixed this in INN 2.3.2 (2.3.1 is one release behind
now). Let's see.... Yup.
date: 2001/01/22 05:53:14; author: rra; state: Exp; lines: +23 -4
Comment the algorithm used to skipped hard-linked articles and silence the
syslog warnings about unknown storage classes for articles that are
> The function tradspool_next in tradspool.c checks to see if an article
> is cross-posted with multiple hard links. If so, it checks to see if
> the current path being examined is not the first path on the Xref line.
> If so, it skips the article by setting "art->len" to 0, since it assumes
> that it will be indexed when it is encountered in the first directory
> listed on the Xref line.
> The error log message given above is what happens when SMgetsub can't
> determine the article class. In this case, it can't determine the
> article class because the article's length has been set to 0 so it can't
> read the Xref header. But that's the behavior we want, since we
> intentionally made the article's length 0, so the error log message is
> completely superfluous.
Yes, this analysis is spot-on. The above fix was similar to the one that
you came up with and is included in INN 2.3.2, as is the following
/* Skip linked (not symlinked) crossposted articles.
This algorithm is rather questionable; it only works if the first
group/number combination listed in the Xref header is the canonical
path. This will always be true for spools created by this
implementation, but for traditional INN 1.x servers, articles are
expired indepedently from each group and may expire out of the
first listed newsgroup before other groups. This algorithm will
orphan such articles, not adding them to history.
The bit of skipping articles by setting the length of the article
to zero is also rather suspect, and I'm not sure what implications
that might have for the callers of SMnext.
Basically, this whole area really needs to be rethought. */
There's a bunch of code in the tradspool implementation that I'd really
like to rework sometime....
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-bugs