perry@vu-vlsi.UUCP (06/10/87)
The man page for expire says ... if you want to rebuild the history file while preserving all articles (as you might want to do on an archival file computer), you must specify expire -r -I -e 999999 -E 999999 to prevent expiration from taking place. and I've been doing that weekly (besides a daily expire -I -e 10) for quite some time. But I noticed a problem last week when a whole batch of duplicate articles over 2 weeks old came in due to a newsfeed problem; they weren't noted as duplicates here and got posted and forwarded on to our downstream sites, one of which recognized them as duplicate articles and notified me. The problem seems to be that 999999 is too large and when that gets converted into seconds inside expire.c it overflows the range of a 32-bit long and produces a wierd result. 999999 * 24 * 60 * 60 = 86399913600 but that same product computed within expire.c produces 500567680 here (Pyramid 90x OSx3.1) The variables used to store the -e and -E times in seconds (expincr and dropincr) are used in expire.c in comparisions of the form: if( rectime + expincr > xxx ) ... so I think that if expincr is very large then (rectime+expincr) can also overflow the range of a 32-bit long and perhaps cause articles to be expired and history records to be removed when they shouldn't be. My solution to this is simple, I now use -e 99 -E 99 Perhaps the news expire man page should be changed to something like that too. ...Rick perry@vu-vlsi.UUCP, perry@vuvaxcom.BITNET Dr. Rick Perry, Department of Electrical Engineering Villanova University, Villanova, PA 19085, 215-645-4224