Re: tradspool tooken weirdness

Hi Christoph,

> So I was looking into ol' tradspool, and took a peek into the history
> file to see when an article is tradspooled. And eventually saw something
> like this:
> 
>      @05630000135A000000000000628500000000@
> 
> Even without checking any documentation it was pretty obivous: Storage
> method 5, class 99, group number 0x135a = 4954, article 0x6285 = 25221;
> and yes, that's it.
> 
> However, this does not match the token description as in tradspool.c:
> 
>      **  The token is @05nnxxxxxxxxyyyyyyyy0000000000000000@
>      **  where "05" is the tradspool method number,
>      **  "nn" the hexadecimal value of the storage class,
>      **  "xxxxxxxx" the name of the primary newsgroup (as defined
>      **  in <pathspool>/tradspool.map),
>      **  "yyyyyyyy" the article number in the primary newsgroup.
> 
> More precisely, the article number part should be eight positions
> further to the left.  And indeed, "sm -c" gets it wrong, check artnum in
> the output:
> 
>      @05630000135A000000000000628500000000@ \
>          method=tradspool class=99 ngnum=4954 artnum=0 \
>          file=(...)/spool/articles/comp/lang/mumps/25221
> 
> Before you freak out, the only real problem is the visual in "sm -c"
> above.
> 
> 
> So, this is on amd64, and I'm certain this happens on all 64 bit
> architentures, or more precisely: Where sizeof(long) is 8 - but I guess
> that's the same thing.

Yes, I also have the same syntax you see for tokens on my amd64 server 
with 8 bytes long.



> There are several ways to get out of this. Quick and dirty, adjust
> tradspool_explaintoken and the documentation.

This would be the easiest and first thing to do.
Sorry for not having seen that.  When I wrote the 
tradspool_explaintoken() function, I was running a 32-bit OS and did not 
spot that.



> Nicer was to make the
> implementation follow the design, replace unsigned long with uint32_t
> when it's about article and group numbers[1], and have a transition in
> the lookup code for the article number. It would check both offsets (4
> and 8), the non-zero one has the actual information. That might as
> well be done as part of an upgrade.

Why would there be a need for a transition?
On a given server, there won't be mixed tokens (ones with 32-bit long 
numbers and others with 64-bit long numbers), and the history file needs 
rebuilding when doing such a change of architecture or 
enabling/disabling largefile support.
When would we have a case of mixed tokens like that in a history file, 
and "sm -c" failing to decode some of them?

-- 
Julien ÉLIE

« Être øu ne pås être, telle est lå questiøn… » (Kerøzen)
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers