Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!pbhyf!rob
From: rob@PacBell.COM (Rob Bernardo)
Newsgroups: comp.mail.elm
Subject: Re: Request For Elm Feature
Message-ID: <4979@pbhyf.PacBell.COM>
Date: 7 Apr 89 23:21:16 GMT
References: <919@itivax.iti.org> <4941@pbhyf.PacBell.COM> <928@itivax.iti.org> <8152@chinet.chi.il.us>
Reply-To: rob@PacBell.COM (Rob Bernardo)
Organization: Pacific * Bell, San Ramon, CA
Lines: 29

In article <8152@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
+In article <928@itivax.iti.org> scs@vax3.UUCP (Steve Simmons) writes:
+
+>>+On another note, we ran out of /tmp space today and users lost
+>>+their messages (Elm 2.1 with some patches, BSD4.3 OS).  Has
+>>+errorchecking been added to handle this?
+
+>>Not yet. This may be a complex task: all fwrites, fprintfs,
+>>fcloses, etc. will need to be checked, and error information passed
+>>up a chain of functions to the proper level where the error can be
+>>appropriately dealt with. . .
+
+>Yeah, I knew how difficult it was when I asked.
+
+Instead of trying to make every function try to do the "right thing"
+on an error, how about just deleting the tmp file and lock and
+DO NOT delete the mailbox file as you bail out.  The only thing that
+would make this even moderately difficult is the variable arguments
+to fprintf() which might prevent a simple macro solution.  Dying with
+an error message may be a little unfriendly, but deleting mail accidentally
+is anti-social.

Hm. I thought the problem was one where the error wasn't detected at all.
When an error is detected, elm does roughly follow the algorhithm you mention.
-- 
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email:     ...![backbone]!pacbell!pbhyf!rob   OR  rob@pbhyf.PacBell.COM
Office:    (415) 823-2417  Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301  R Bar JB, Concord, California