I was recently charged with overhauling our institutional mailing
system. It has turned out that one of the principal issues is the
coordination of locking policies between MTAs and MUAs. For various
reasons, our MTA uses "dot-locking", i.e. atomic creation of dummy a
dummy file "mailbox.lock" alongside the file itself, "mailbox".
Along the way, I checked XEmacs and found out that locking seems to be
an OS issue, but can be configured. --mail-locking=file was supposed
to do the trick, and configure reports that it's using "dot-locking".
However, this is a lie: movemail only uses dot-locking in the absence
of other locking methods. Since quite a few src/s headers declare a
locking method, dot-locking never gets used on these systems.
So, obviously, there's a bug here. I could fix it, but I think the
whole mail-locking issue is conceptually broken in XEmacs:
- The locking policy is not an OS issue, but rather a site issue.
The OS issue is what policies *work*, not which ones are in use.
- This means our binary kits are broken by design on many sites.
I therefore propose the following changes:
The locking policies can be controlled through three mechanisms (by
descending precedence):
- Specification on the movemail command line.
- Specification of an environment variable EMACSLOCKMETHOD with the
same possible values as the --mail-locking argument to configure.
- Configuration via autoconf and src/config.h.
Moreover, XEmacs itself should have a variable `mail-lock-method'
(values 'file, 'lockf, 'flock) initialized from a variable
`configure-mail-lock-method' set by autoconf which prompts XEmacs to
call movemail with the appropriate command-line argument. Of course,
this will take convincing the various XEmacs MUA package authors.
If nobody objects by the upcoming weekend, I'll implement this.
Opinions?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
