Path: utzoo!yunexus!ists!shields
From: shields@ists (Paul Shields)
Newsgroups: comp.mail.elm
Subject: Re: elm just ate my mailbox .......
Summary: almost what I'm looking for.  How about lockf() ?
Keywords: elm, SunOS 3.5, NFS, lockf()
Message-ID: <108@ists>
Date: 16 May 88 06:32:04 GMT
Article-I.D.: ists.108
Posted: Mon May 16 02:32:04 1988
References: <372@m3.mfci.UUCP> <2287@newton.praxis.co.uk>
Organization: Institute for Space and Terrestrial Science
Lines: 30

In article <2287@newton.praxis.co.uk>, tkr@praxis.co.uk (Tim Rylance) writes:
[...]
> In fact Elm *never* checks for errors after writing.  I went through it 
> adding checks and trying to do something reasonably intelligent when a
> write fails.  I now give up immediately if /tmp is full on startup, and
> I copy /tmp/mbox.foo back to /usr/spool/mail/foo.<pid> and then rename
> the latter to avoid abandoning mail in /tmp if /usr/spool is full.
> I also removed the use of temporary file names constructed from getpid()+1
> and replaced the mailbox locking code (which appears to contain a race)
> with that from GNU Emacs.
[...]

The posted solution to this is nifty, but is not precisely what I'm looking
for. I'm trying to bring Elm 1.7 beta up under SunOS 3.5, and have encountered
difficulty with locking files across NFS.

Apparently the lockf() procedures in conjunction with the lockd daemon will 
do it for me.  But this raises compatibility issues, since I don't want
the mail delivery software to interfere, and the GNU code seems to use only
flock() or lock files, not lockf(). 

Has anyone fixed this yet?  Except for new mail delivery it doesn't appear
to be too much trouble, but I thought I'd ask first just in case anyone's 
already done this.

Thanks,
-- 
Paul Shields, shields@ists.yorku.CA, shields@yunccn.UUCP
(...utzoo!yunexus!ists, ...mnetor!ontmoh!yunccn)!shields
I wonder what Freud would have thought of self-serve gas stations?