Complexity of reallocating storage (was users command crap)

[terryl at sail.LABS.TEK.COM]

In article <29421:Feb419:13:5891 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <4702 at goanna.cs.rmit.oz.au> ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>> Er, what about the disc running out of I-nodes?  Or going over quota?
>> Or a file server dropping dead?
>
>Well, yes, but those fall under the blanket of ``fatal errors'' which I
>mentioned at the top of the article. (Actually, going over quota
>shouldn't happen unless the system is strangely configured, but this is
>beside the point.) There's a push-pull here between ``don't catch errors
>you can't handle sensibly'' and ``don't dig your hole too deep.''

     Now, I'm reading between the lines here, but this is what I see:

     Many people have pointed out ways things can go wrong, but you just hand-
wave them away as "fatal errors" (errors that you can't possibly fix).

     Now, what I see (and from examining the code fragment from pty/master.c)
is that quite a few of the things you claim "cannot happen", could very well
happen, but your program will blindly plow on, possibly dumping core.

	<ENTER VERY IMHO MODE>

     There's nothing I hate more than programs that silently fail, because I
can't tell WHY they failed. Even just a simple "I can't do this because of that"
is preferable (like perror(filename)). At least I can say "Aha, over quota;
better delete some files." Also, don't tell me "Cannot open file", even if file
is a real live filename. Tell me WHY you can't open it.

	<EXIT VERY IMHO MODE>

__________________________________________________________
Terry Laskodi		"There's a permanent crease
     of			 in your right and wrong."
Tektronix		Sly and the Family Stone, "Stand!"
__________________________________________________________