home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.mail.elm
- Path: sparky!uunet!uchinews!machine!ddsw1!dattier
- From: dattier@ddsw1.mcs.com (DWT)
- Subject: Re: Elm folder locking problems
- Message-ID: <Bz4B05.28u@ddsw1.mcs.com>
- Date: Fri, 11 Dec 1992 23:09:40 GMT
- References: <1992Nov27.185006.23849@syma.sussex.ac.uk> <1f83gmINNrev@dsinc.dsi.com> <1992Dec7.172021.13658@syma.sussex.ac.uk>
- Organization: Contributor Account at ddsw1, Chicago, Illinois 60657
- Lines: 27
-
- samuele@syma.sussex.ac.uk wrote in <1992Dec7.172021.13658@syma.sussex.ac.uk>:
-
- | The problem is
- | the fact that Elm doesn't honour the locks placed by procmail - if it did
- | then it would just have to wait until procmail removed the locks and then
- | the read would work fine.
-
- Ah, but for your main incoming mailbox you can make procmail honor the locks
- placed by Elm. For other folders you can use procmail's lockfile utility to
- let the mail user agent get and hold the lock until you're done.
-
- If you tell procmail to use /tmp/mbox.$USER as a local lockfile on any recipe
- that delivers to your main mailbox (called $ORGMAIL in procmail parlance, and
- to which procmail's $DEFAULT variable is usually equal as well), that should
- make procmail wait for Elm if you're already reading mail (and Elm refuse to
- start while procmail is delivering to your main mailbox). You'll have to
- exit Elm and return for your waiting mail to get delivered, but that beats
- a corrupted mailbox.
-
- | Ermmm, so if I want to try and fix Elm so that it looks for locks on
- | folders before it resyncs them then this might do the trick, and I could
- | then give this to the dev group for the next version?
-
- I don't see any need to change Elm.
-
- David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
- dattier@ddsw1.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818
-