Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!decvax!ittvax!swatt
From: swatt@ittvax.UUCP
Newsgroups: net.bugs.uucp,net.mail,net.flame
Subject: Re: BUG in System III [and others] UUCP (FLAME)
Message-ID: <1243@ittvax.UUCP>
Date: Tue, 17-Jan-84 17:02:02 EST
Article-I.D.: ittvax.1243
Posted: Tue Jan 17 17:02:02 1984
Date-Received: Wed, 18-Jan-84 07:39:34 EST
References: rlgvax.1549
Lines: 21

The fix Guy Harris mentioned was done that way deliberately.  The UUCP
sources I worked with had a notion of error codes, one of which was
"Can't make temp" (or some such).  The code *looks* like the system
attempting to send a file will just abort that particular transmission
and go on to the next.  In fact, it will avoid deleting the D.<mumble>
file, but *will* delete the C.<mumble> file which references it, for
reasons of the very obscure module function partitioning in UUCP which
I would much rather not have to call to mind right now.

If the receiving system uses this error code to signal not enough disk
space, the transmitting system will end up with an orphan D.<mumble>
file that will never get sent.

The only sure way I could find to keep the sending system from deleting
anything was to cause the whole connection to fail.  At worst, this
means the two systems in question will thrash at the retry period until
someone comes along and gets enough space back in the spool filesystem.
What I should have done, but didn't, was to log the out of space
condition so it could be noticed immediately.

	- Alan S. Watt