🚀 go-pugleaf

In article <1992Aug27.185938.21422@leland.Stanford.EDU> mosedale@genome.stanford.edu (Dan Mosedale) writes:
>However, as I understand it, due to various bugs in various vendors'
>rpc.lockds, this is running the risk of getting one's mailbox
>thoroughly hosed if more than one process tries to write the mailbox
>at once.

How about, "due to various bugs in various vendors' rpc.lockds, said
vendors don't even trust them enough to use them in their own software"?
- As far as I know, neither /bin/mail nor /usr/ucb/mail in SunOS do any
lockf() etc calls, but rather rely on "traditional" Unix locking,
checking for a /var/spool/mail/user.lock file. (I verified this for
/usr/ucb/mail by using trace - it did use flock(), though...)

Of course the lockfile method doesn't really work reliably over NFS
either (but probably better than rpc.lockd:-) - nevertheless, for what
it's worth, I have never heard of anyone getting bitten by this, and
NFS-mounting /var/spool/mail is just about the norm around here (as is
SunOS) - of course the probability of clashes depends on how much mail
you're getting.

The risk is presumably further reduced by keeping time well in sync
between server and client (we use NTP), and by mounting /var/spool/mail
with the 'noac' option. And of course *delivery* of mail should be on
the server only.

--Per Hedeland
per@erix.ericsson.se  or
per%erix.ericsson.se@sunic.sunet.se  or
...uunet!erix.ericsson.se!per