🚀 go-pugleaf

In article <584@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore)
writes:
| Perhaps the original question should have been:
| 
| How does the mail software deal with *file* locking over NFS?

The tradional way mail has handled locking is as follows:

When some mail agent (/bin/rmail to deliver new mail, or any of
mailx/Mail/mh/elm to delete old mail) wants to modify the mailbox for
a user "joe", it creates a file in the spool directory with ".lock"
tacked on (/usr/spool/mail/joe.lock for BSD systems,
/usr/mail/joe.lock for system V), with options to open to fail if the
file exists.

If the file exists, it means that some process is updating the
mailbox, and the process loops for some period of time trying to gain
access to the mailbox.  As soon as the mailbox is not being updated,
the lock should be removed.  For example, when you read the mail, your
mail reader should lock the mailbox, read the mail file into a private
spool file, and unlock it immediately, and then let you read, delete,
file, etc. the mail at your leisure.  At the end, it would do the lock
again, do any changes, and unlock.

The biggest downfall of this scheme is if the system or mail agent
crashes, your mailbox is left locked.  Another problem, though more
minor, is that other programs attempting to lock the mailbox, are not
notified when the mailbox is unlocked.

Some schemes (system V) put the pid in the lockfile, and use
kill(pid,0) to determine if the locker is still there, and if not
break the lock.  This generally can cause problems in an NFS
environment, since pids are local to each system.

There are two problems with using flock/lockf/fcntl to lock the
mailboxes, 1) until recently NFS did not allow locking; and 2) all of
the other programs that dealt with locking (such as elm) would have
to change as well (this has been a problem for elm in the past).

I hope I haven't bored the old-timers out there......
-- 
Michael Meissner, Data General.

Uucp:	...!mcnc!rti!xyzzy!meissner
Arpa:	meissner@dg-rtp.DG.COM   (or) meissner%dg-rtp.DG.COM@relay.cs.net