Another VirtualPath-type bug

[Just Another Victim of the Danish Usenet Afrydder-Mafia]

On 22 Jun 19100, Katsuhiro Kondou wrote:

> }     /* XXXXX seems b0rkened...  if (VirtualPathlen > 0) { */
> }     if ( (VirtualPathlen > 0) && (what != STbody) ) {
> } -->>    if ((path = (char *)HeaderFindMem(ARThandle->data, ARThandle->len, "path", sizeof("path") - 1)) == NULL) {
> 
> I cannot find 'if ( (VirtualPathlen > 0) && (what != STbody) ) {'
> line in nnrpd/article.c.  Is your code modified, isn't it?

Um, yes, the original line is commented just above it....

This is to fix a bug which I found the day before, which didn't
seem to make it to this list (I'm reading by news and only now
has this article shown up), in which command `BODY' with a
virtual host defined returned nothing to the expectant victim.


(I can't remember from what machine I sent that bug report and
patch, whether or not I would have a copy of that mail, but you
see the needed change above)


I haven't done much research on the problem `path' that I am
now reporting, but the articles where I do notice it are in CNFS
buffers, and often I see the entire article from the start of the
contents of the Path: header past the end and overlapping the
overwritten article in the buffer.

Since HeaderFindMem() seems to fill `path' with more than just
the contents of the Path: header on articles in regular spool,
is it possible it's being corrupted by reading from a CNFS
buffer somehow?  Just a speculation, since I haven't looked at
a large quantity of traditional spool article groups...


I see more problems now, concerning the spool filling up and
throttling in a weird way, but I'm not anywhere that I can make
a useful report on just what's happening there at the moment.


(Please to take advantage of sparkly reply-to header, as I have
just booted a several-year-old OS which is not at all configured
for my present connectivity)