Xref: utzoo comp.mail.elm:3239 comp.sys.apollo:6895
Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!caen!ox.com!b-tech!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.mail.elm,comp.sys.apollo
Subject: Re: Elm on HP-Apollo Domain's : Problem!
Message-ID: <4d9c78a7.1bc5b@pisa.ifs.umich.edu>
Date: 25 Oct 90 16:13:32 GMT
References: <692@spinifex.eecs.unsw.oz>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 26

In article <692@spinifex.eecs.unsw.oz>, ashley@usage.csd.oz (Ashley Aitken) writes:
  Any suggestions on how I can save Elm from being purged would be gratefully
  accepted. I am sure there are other Apollo sites out there using Elm.

Here is the correct way (or at least, a correct way) for mailers to handle
user's mail spool files (/usr/spool/mail/joe_user):

Try to open the file for exclusive use (read or write, as needed).
If it's locked, sleep for a few seconds and loop as needed.
If you can't get it after half a minute or so, return an error.
When you get the file open, read or write it, then close it.
Don't leave it open while the user is sitting there reading his mail,
  for example.

This will ensure that everyone gets exclusive use of the file.  I happen to
like Apollo's implicit file locks.  They make it easier to write distributed
applications and operating systems.  Unfortunately, the rest of the Unix
universe seems to either ignore the problem or use explicit locks, which I
find harder to think about and harder to use.

You can do all this with ios_$ call, and I think you can do it with regular
Unix calls now, too.  For some sample code, see the Apollo B news patches,
file apollo.c.

The stupid thing is that the mail programs that come with your Apollo don't
conform to the Apollo file locking rules.