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
honey@down.UUCP (code 101) (01/21/84)
just to review, the issue at hand is the proper handling of SN4 codes in cntrl.c: what should my side do if your side runs out of space? this question was the subject of heated discussion at one point among redman, bellovin, nowitz and myself. our thoughts in brief. we agreed from the outset that it was imperative that my side abort processing of the current C. file. someone proposed that the next C. file be considered; it was pointed out that in all likelihood, that transaction (and all subsequent ones) would also fail. (the overwhelming majority of file transfers are sends, not receives). you then would have to be careful to avoid looping when the directory is rescanned. (this is not outrageously hairy, in practice.) it can be argued that the wisest course is to inspect the remaining C. files for receive requests, process those, then switch roles (i.e., request to hangup), with a switch in anlwrk.c to avoid the loop (on a later role change). we felt that, among other things, this complexity would eventually come back to haunt us, so we took the easy way out: we hang up. peter honeyman