chris@umcp-cs.UUCP (12/31/83)
Oh yeah, that bug. That's in gio.c. Look for the "fwrite" calls. If
they fail return a FAIL. Seems to work well enough now.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relayguy@rlgvax.UUCP (Guy Harris) (01/14/84)
The "gio.c" that comes with the 4.2BSD UUCP does do this checking; however,
be warned that the routine above it doesn't do anything pleasant with the
error return. It just says "oops, something failed, the h*ll with it" and
terminates the entire UUCP session, so if a file is too big for the file
system the spool directory is on (or exceeds the "ulimit" maximum file size
on USG systems), or gets a write error, or if a file being sent has a bad
block in it, the UUCP session will terminate with no more meaningful
diagnostics than "FAILED (conversation complete)". It *does* get caught,
but doesn't get reported properly back to the user at all (and would take
a bit of jerking the code around to do so, which is probably why it wasn't
done).
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyswatt@ittvax.UUCP (01/18/84)
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