[comp.mail.elm] Elm for 4.3BSD?

mb@ttidca.TTI.COM (Michael Bloom) (10/15/87)

Has anyone modified ELM to use flock(2) instead of lock files?  I have
elm running on my home 4.2 system (and it's a pretty nice mail agent),
but can't safely install it on the 4.3 systems at work.

Why? Because 4.3 uses flock instead of lock files for mail file
locking and replacing the file locking code in elm does not look
trivial from what I've seen.  the locking code in elm is scattered and
is used on files that are closed in some places, open in others.
flock only works on open file descriptors, and the combinations of
locking via lock files, opens and closes in the elm code do not lend
themselves to simple replacement with flock style locking.

Has anyone already made elm use flock?  If so, please post your mods,
as this one facet of elm may be preventing it from being used at many
more sites than just my own.

If not, I'll probably get around to making the changes myself, but it
looks like it will involve reorganization of quite a bit of code, and
I just don't have the time for that right now.

- Michael Bloom (mb@ttidca.tti.com)

davis@hplabsb.UUCP (10/22/87)

In article <1355@ttidca.TTI.COM> mb@ttidca.UUCP (Michael Bloom) writes:
mb>	Has anyone modified ELM to use flock(2) instead of lock files?
mb>	. . . but can't safely install it on the 4.3 systems at work.
mb>	Why? Because 4.3 uses flock instead of lock files for mail file
mb>	locking . . .  the locking code in elm is scattered and
mb>	is used on files that are closed in some places, open in others.
mb>	flock only works on open file descriptors, and the combinations of
mb>	locking via lock files, opens and closes in the elm code do not lend
mb>	themselves to simple replacement with flock style locking.

    Skill is a reasonable requirement from the author of Elm, but
clairvoyance seems to be too much to ask for.  At the time that
Elm was written, the mailbox locking protocols didn't use flock()
or lockf().  Elm made an attempt to use a reasonably compatible
protocol.  I say that because Sys V /bin/mail and Sys V mailx
have different, incompatible (subtly so) protocols.  Sys V mailx
and BSD 4.2 mail have the same protocol, but it times out far
too quickly.  I speak here as one who has had system mailboxes
trashed over a dozen times.

    Elm's mailbox locking code seems to be in lock() and unlock() in
src/leavembox.c.  filter/actions.c has inline "creat" mailbox locking
code.  There is also locking code in utils/arepdaemon.c but not for
locking mailboxes.  Thus it looks like Elm's mailbox locking code is
in but two places (one too many).  As for its neglect to always hold
open the mailbox, that would be an error.  To use flock() (or lockf())
style locking, you should make sure that Elm holds the mailbox
file open for the minimal time period.  As a "brute force" solution
to the problem you face, why not modify the lock() routine in Elm
to open the mailbox (*again*) and flock() it, then modify the
unlock() routine to un-flock() it and close the redundant open?

    No I haven't implemented the above, but that's because I
don't have source to all of my other mailers.  They use
(various) lockfile locking protocols, so Elm had better not
use lockf() for me.
				-- Jim
----------------------------------
		Jim Davis (James W Davis)
Email:		{any_of_the_biggies} !hplabs!davis
Arpa/Domain:	davis@hplabs.hp.com
----------------------------------