Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake
From: shwake@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.unix.i386
Subject: Re: Mail not delivered in MMDF Mail under SCO UNIX
Summary: background deliver solves problem for some, not for me
Keywords: MMDF SCO-UNIX deliver
Message-ID: <107@raysnec.UUCP>
Date: 16 Jul 90 14:53:54 GMT
References: <678@mecky.UUCP> <7590@gollum.twg.com>
Reply-To: shwake@raysnec.UUCP (Ray Shwake)
Distribution: usa
Organization: IRS - ACI Project Office
Lines: 20

In article <7590@gollum.twg.com> david@twg.com (David S. Herron) writes:
>
>This "lock problem" you mention is not a problem at all.  What would
>happen if you had two processes scribbling mail into your mailbox
>at once?  Why, confusion, that's what!  In order to avoid the confusion
>MMDF locks the mailbox while it's writing to it.  Similarly, the local
>channel gives up when it can't get the lock on the mailbox.  The way
>in which it gives up leaves the message in the queue directory.

	As I've already pointed out to David (Hi, guy!) having deliver
	run as a background daemon still doesn't guarantee that the 
	message will finally be delivered. I know. Every few days I
	find orphaned files in mmdf/lock/home.

	The need to lock the destination box is obvious. But it's dis-
	heartening to work with a system that can't properly post more
	than one message to a single box in rapid succession. The
	sdaemon I use (and its rmail variant) test for the presence
	of a lock file for ten seconds at one second intervals. Yet it
	posts so quickly I've YET to trip it up.