Julian Assange wrote:
>
> RFC says \r\n. If you look at the inn source you will see that it also
> does \r\n, so I'm a little puzzeled myself.
I'll try to track it down when I get time. It seems that what happens is
that nntpcached puts an extra \r every (x) number of lines. That is, the
differences are sporadic.
> > PS Julian, did you see my mail about outbuf_used not being reset in xover.c?
>
> Yes. Fixed, although I'm not convinced it was broken ;)
OK, I'll convince you right now:)
static void xf_release_writer (struct xover_file *xf)
{
xf->writer = FALSE;
if (xf->outbuf)
{
free (xf->outbuf);
xf->outbuf = NULL;
}
...
}
This function is always called at the end of an xover transfer and it
wipes out the outbuf in memory. Note that it does not touch xf->outbuf_used.
static bool xover_input (char *xhdr, int min, int max)
{
...
if (i32 == 0 || i32 == 0xffffffff) /* only if we don't have it already */
{
idx[response % MI] = htonl ((len << 20) | (((xf->size > 0) ? xf->size : MI * 4) + xf->outbuf_used));
#define GRAB_SIZE 32768
if (!xf->outbuf)
{
xf->outbuf = Smalloc (GRAB_SIZE);
xf->outbuf_len = GRAB_SIZE;
} else if (xf->outbuf_used + len > xf->outbuf_len)
xf->outbuf = Srealloc (xf->outbuf, (xf->outbuf_len += GRAB_SIZE));
memcpy (xf->outbuf + xf->outbuf_used, p, len);
xf->outbuf_used += len;
Stats->xover_cached_bytes += len;
Stats->xover_cached++;
}
...
}
Consider two consecutive xover commands in the same 512 block. When the
second one is processed, the corresponding xf will be already in memory,
and data will have been written the corresponding file. So xf->outbuf_used
is non-zero and xf->outbuf is zero. This means that xf->outbuf_len will
end up being GRAB_SIZE. When we come down to the memcpy call anything
could happen, as xf->outbuf_used contains some value that is totally
irrelevant to what we are doing.
>
> > PPS There's still a problem in CMDarticle when an alternate server is used
> > for getbyid and the function does not reset CurrentScfg after the transfer
> > causing subsequent "Bad articles", etc. Is it OK to just reset CurrentScfg
> > at the end of CMDarticle?
>
> No. The idea is that if a getbyarticleid was performed sucessfully the
> previous time CMDarticle was called, then when it is called the second time,
> the chances are that the second article will be on the same server as the
> first. This saves scanning the available servers for the article ID. It
> is primarily for this reason that there is a CurrentScfg as well as a
> CurrentGroupScfg, although from what you say, the mechanism isn't working
> 100% correctly. I've now added a CurrentIDScfg, which points to the
> last successfully handled <msgid> server.
I guess it's kind of similar to the group problem. We switched server to
get some articles, but the next article command that comes along is probably
not a getbyid, thus requiring the attention of the original server. Thus
I think we can probably get by with something like
if (!getbyid && CurrentScfg != CurrentGroupScfg) CurrentScfg=CurrentGroupScfg;
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
Email: Herbert Xu ~{PmV>HI~} <herbert@greathan.apana.org.au>
{ http://greathan.apana.org.au/~herbert/ }
PGP Key: pgp-public-keys@pgp.mit.edu or any other key sites
