jeff@ssc-vax.UUCP (05/27/83)
In expire.c there is a problem in mkparents() which causes the
subsequent chmod() and chown() syscalls to fail because they are being
called with a first argument of "mkdir <buf>" rather than with
"<buf>". In mkparents(), add the indicated sprintf to fix:
.
.
mkparents(buf);
sprintf(sysbuf, "mkdir %s", buf);
rc = system(sysbuf);
+ sprintf(sysbuf, "%s", buf);
if (verbose)
printf("mkdir %s, rc %d\n", sysbuf, rc);
chmod(sysbuf, 0755);
if ((pw = getpwnam(NEWSU)) != NULL)
chown(sysbuf, pw->pw_uid, pw->pw_gid);
return(0);
}
hokey@plus5.UUCP (Hokey) (07/15/84)
I have discovered the undocumented feature in expire which I will call the "controlling newsgroup" feature. This feature provides for the disposition of an article under expire based on the first newsgroup in a list of multiple newsgroups. When using the -n option of expire, the list of newsgroups goes into the variable 'ngpat'. Somewhere just after the comment: /* Nothing after the 2nd tab in the Big Loop in expire.c there is a line of code which contains: if (!ngmatch(groupdir, ngpat)) { This can be found at line 227 in my 2.10.1 expire, and at line 323 in 2.10.2 expire. groupdir contains the FIRST NEWSGROUP in the list from the line in the history file (with the /article stripped). So, if you are attempting to use multiple invocations of expire to either delete or archive selected groups (the last one is where it really hurts, because your article won't be archived) using the -n option to limit the list of newsgroups, beware! Does anybody think this is *really* a feature? expire, be advised that -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jf@sal.UUCP (Johan Finnved) (03/31/85)
PROBLEM: We are running news version B 2.10.1 6/24/83 (MC840302) and I have noted that expire crashes halfway through its work. This is because it gets out of memory in the routine "hread()" as unrecognized header lines are read into memory that is allocated with "malloc()" (without error checking of course). Since expire reads all files in the news database "hread()" gradually consumes more and more memory until malloc fails and the next unrecognized header line gets read into location zero .... SOLUTION: To fix the problem I have added an entry "hfree(hp)" in the module header.c to free storage allocated by "hread()", and I have added a call to "hfree()" in the main loop of expire.c (just after the call of hread since the unrecognized header fields aren't needed at all. I didn't want to free the storage in the beginning of hread (before it zeroes the header) since I don't know if the header sometimes gets allocated on the stack and thus can contain garbage that should not be mis-interpreted as pointers to storage to free. Johan Finnved <jf@sal.UUCP> OBJECTA Elektronik & Data AB, Sweden