fletcher@cs.utexas.edu (Fletcher Mattox) (07/05/90)
I'm runnning 7.1.1 with DOT_LOCK and HOMEMAIL defined, but not MMDF. When mush read locks the spool mail file while it incorporates new mail into the temporary file, I occasionally see something like this: New mail (#646) TO: fletcher Jul 4 14:56 (13 li) JUNK Msg 639 of 646: /v/ai/v0/fletcher/mailbox already locked, waiting.done. New mail (#647 thru #648) TO: fletcher Jul 4 14:57 (13 li) JUNK TO: fletcher Jul 4 14:57 (13 li) JUNK Msg 639 of 648: Can't load new mail: "/v/ai/v0/fletcher/mailbox" may be corrupted! The above example was produced by sending myself several pieces of JUNK mail and typing <return> periodically at mush. It happens with "real" mail too. Usually the spool file is not corrupted, the error message notwithstanding. The dot_lock code seems to be working. I'm not sure why load_folder() is failing. Any ideas? An aside: I notice README-7.0 sez read locking was not supported for DOT_LOCK. Did that change? It clearly is supported in 7.1.1 (for which I am glad--my temp file was constantly getting truncated under 6.5.6 when new mail arrived).
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (07/05/90)
In article <9699@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: } I'm runnning 7.1.1 with DOT_LOCK and HOMEMAIL defined, but not MMDF. } } When mush read locks the spool mail file while it incorporates new mail } into the temporary file, I occasionally see something like this: } } Can't load new mail: "/v/ai/v0/fletcher/mailbox" may be corrupted! } } The dot_lock code seems to be working. I'm not sure why load_folder() } is failing. Any ideas? The function which checks the arrival of new mail was not properly recording the size of the mailbox, causing it to attempt to read more than once. We'd already noticed this in connection with a different problem, and patch 2 will include a fix. } An aside: I notice README-7.0 sez read locking was not supported for } DOT_LOCK. Did that change? It clearly is supported in 7.1.1 (for which } I am glad--my temp file was constantly getting truncated under 6.5.6 } when new mail arrived). What README-7.0 says is still correct, albeit a tad unclear. What is really meant is that *shared* (as opposed to exclusive) locking is not supported for DOT_LOCK. Normally, mush uses a shared lock on read so two processes could be reading the same folder simultaneously; an exclusive lock is used on write so that reading+write or write+write cannot happen simultaneously. With DOT_LOCK, even read+read is stopped. -- Bart Schaefer schaefer@cse.ogi.edu