Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!ogicse!schaefer
From: schaefer@ogicse.ogc.edu (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: read locking corrupts mailbox?
Message-ID: <10337@ogicse.ogc.edu>
Date: 5 Jul 90 01:39:57 GMT
References: <9699@cs.utexas.edu>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 29

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