NNTPC: One 'memory currupt' fixed + caching question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I wrote:

> Now for a question. If I access an article by article number within a
> group, it is read from the upstream feed the first time, and returned
> from the cache if I access the same article number again. On the other
> hand, if I access the same article by message ID, it is read from the
> upstream feed every time:
> 
> Jan 30 12:31:03 newscache ./nntpcached[4504]: sockets.c:366: <- article <rzq680fh1n1.fsf@djlvig.dl.ac.uk>
> Jan 30 12:31:03 newscache ./nntpcached[4504]: sockets.c:402: => [doffen.uninett.no] article <rzq680fh1n1.fsf@djlvig.dl.ac.uk>
> Jan 30 12:31:04 newscache ./nntpcached[4504]: article.c:187:File exists: unlinking pre-existing article comp/unix/bsd/freebsd/misc/38047
> Jan 30 12:31:04 newscache ./nntpcached[4504]: article.c:247: adding <rzq680fh1n1.fsf@djlvig.dl.ac.uk>:doffen.uninett.no/comp/unix/bsd/freebsd/misc/3804 to cache.history (suceeded)

I believe I have now fixed this bug. The patch is very simple:

*** article.c.0	Sat Feb  8 01:21:55 1997
--- article.c	Sun Feb  9 16:13:55 1997
***************
*** 232,238 ****
  		char *p = strchr (artfile, '_');
  		if (p)
  			*p = '\0';
! 		sprintf(buf, "%.382s/%.31s", CurrentDir, artfile);
  		if (safePath(buf))
  		{
  			rfc822lower (msgid);
--- 232,238 ----
  		char *p = strchr (artfile, '_');
  		if (p)
  			*p = '\0';
! 		sprintf(buf, "%.127s/%.287s", CurrentDir, artfile);
  		if (safePath(buf))
  		{
  			rfc822lower (msgid);

This is inside the crosspost() routine, and just before calling crosspost(),
(in CMDarticle()), CurrentDir is set to the top level server name. It does
*not* include the full path name of the article. 'artfile' includes the full
path, and can become much longer than 31 characters. In my case, it was 32
characters, which resulted in the last digit of the article number being
left off, and the wrong entry added to the history file. Thus the history
file entry would never match the actual file name, and the article would be
retrieved from the upstream server every time.

With this patch and a rebuild of the history file, my problem is gone.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no


[Index of Archives]     [Yosemite]     [Yosemite Campsites]     [Bugtraq]     [Linux]     [Trn]

Powered by Linux