Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site decvax.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harpo!decvax!larry From: larry@decvax.UUCP (Larry Cohen) Newsgroups: net.unix-wizards,net.bugs.uucp Subject: Re: UUCP ignoring work requests Message-ID: <7@decvax.UUCP> Date: Mon, 4-Jun-84 09:26:37 EDT Article-I.D.: decvax.7 Posted: Mon Jun 4 09:26:37 1984 Date-Received: Wed, 6-Jun-84 01:04:14 EDT References: <19574@wivax.UUCP> Organization: DEC UNIX Engineering Group Lines: 20 I have seen this phenomena also (not sending out spooled files for a period of time). In the cases I have seen the problem is related to corrupted C. files. Every so often (couple of times a year) I have found a C.file that appears to contain the output of a news or mail data file. Most versions of uucico will read a line in this C. file and determine that there are too many arguments and subsequently exit via an ASSERT call. This explains why no files are transferred - uucico never gets past the bad C.file. The reason things clear up after a week (at least on the systems I have worked on) is that we have a crontab shell script which will remove files which have been sitting around too long (usually a week). I dont know why the bad C.files appear but I have been able to work around the problem by having uucico move the corrupted C.files to a safe place - something like /usr/spool/uucp/BADCFILES. If anyone knows the the answer to the corrupted C.file problem I would sure like to know. -Larry Cohen decvax!larry