Mail problem under SCO UNIX V/386 Release 3.2 -- Loss of Mail

David S. Herron david at twg.com
Mon Aug 13 15:40:55 AEST 1990


In article <17 at raysnec.UUCP> shwake at raysnec.UUCP (Ray Shwake) writes:
>irv at happym.wa.com (Irving Wolfe) writes:
>
>>If two messages arrive from another system in the same uucp session for a user 
>>while he is in mail, one of the messages can get lost.  The uucp logs on both 
>>ends show successful passing of both pieces of mail, but the user is only 
>>notified of the first piece and the second piece goes to never-never-land (at 
>>least sometimes). 


As as been said before ... this is *NOT* a problem except in
the configuration you run.  MMDF, as do all other mail systems,
puts out a lock on the mailbox wile delivering mail.  The lock is
there so that you don't have >= two processes scribbling on the file
and making a mess of things.  Now .. at some point, before I got involved
with MMDF, a decision was made that the local channel will simply exit
when it see's the mailbox is locked (and exit in a way which tells
the deliver controlling it that there's a temporary problem, rather than
a permanent problem for which it should bounce the mail back to the sender)

Part of this decision was an assumption that the system had a deliver
running in the background controlling mail traffic on one-or-more channels.
The command line to do this is:

	deliver -cchan,chan,chan -b
(for instance):	deliver -cuucp,local,list -b


I have no idea why a simple heuristic wasn't used to, when the open+lock
failed, simply wait a little while and try again.  It's something I plan
to do with the version of MMDF which I maintain.  I have no idea what SCO
plans to do with the version of MMDF they maintain ...

-- 
<- David Herron, an MMDF weenie, <david at twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david at ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!



More information about the Comp.unix.i386 mailing list