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