Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ncr-tp.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcc6!ncr-tp!greg From: greg@ncr-tp.UUCP (Greg Noel) Newsgroups: net.bugs.uucp Subject: Re: P-E 3220 can't talk to 11/70 running 4.2BSD uucp (for large files) Message-ID: <114@ncr-tp.UUCP> Date: Thu, 13-Dec-84 21:57:41 EST Article-I.D.: ncr-tp.114 Posted: Thu Dec 13 21:57:41 1984 Date-Received: Sat, 15-Dec-84 02:58:48 EST References: <194@lsuc.UUCP> Reply-To: greg@ncr-tp.UUCP (Greg Noel) Distribution: net Organization: NCR Corporation, Torrey Pines Lines: 26 In article <194@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: > On large files, uucp dies >partway through creating a large TM.* coming to us. It stops >at a different place each time. The news feed requires large >files because of batching. I suspect the problem is that your lock files are timing out. The dates on the lock files are set only at the beginning of each file transfered. If the transfer takes longer that the lock timeout period, some other incarnation of uucico will come along and break the lock, killing the in-progress transfer. This could happen at either end of the link. I had this problem; I fixed it by installing a temporary version of uucico with an essentially infinite timeout period. A better solution would be if uucico were to touch the lock files periodicly, say after every 50,000 bytes transfered, but I didn't have any time to really look into that (I only had one large file that needed to be transfered). Another way of doing it that occured to me later, and which would work even for a binary site, would be to babysit the transfer and manually touch the lock files. Not fun, but the file would be transfered. I'm surprised that your news feed is creating batches that are so large that this problem is caused; this is one reason why most batchers limit the batch size. -- -- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA