tradspool tooken weirdness
Julien ÉLIE
julien at trigofacile.com
Thu Dec 21 19:58:22 UTC 2023
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)
More information about the inn-workers
mailing list