On Tue, 2004-10-19 at 10:42, Ron Johnson wrote: > On Tue, 2004-10-19 at 09:47 -0400, Norman P. B. Joseph wrote: > [snip] > > Mail here is delivered locally to a mailhub machine whose > > /var/spool/mail directory is NFS mounted to clients like mine. I have > > my evo mail account set up with a server type set as "Local Delivery", > > meaning evo periodically checks the NFS mounted spool directory and > > moves any messages found there to my inbox under ~/evolution/local. I > > mention this since it seems the likely place for where the process might > > be broken. > > Isn't it like a *huge* no-no to share (MUA & MTA) an mbox file > across an NFS link????
It's been my observation that what evolution does for a "Local Delivery" account is to periodically copy the contents of the file "/var/spool/mail/user" to" ~user/evolution/local/Inbox/<some temp file>" and then process the messages from the temp file, appending messages to ~/evolution/local/Inbox/mbox and other folders as the messages trigger filtering rules. The greater the frequency of checking /usr/spool/mail/user for new messages, the smaller the amount of data that needs to be copied atomically, and the smaller the window for locking issues. In practice here for years, both well before evolution (insert fond remembrances of Elm and Z-mail under IRIX), and well after, NFS mail spool locking has never been an issue. Even so, its hard to imagine how a locking problem would manifest itself in the behavior I described earlier. If the local delivery agent on the /var/spool/mail host doesn't see a lock set by my host and begins appending a message to the mailbox while evo on my host is copying the mailbox to its temp file under ~/evolution/local/Inbox, I would expect to see the beginning of a partial message at the end of the mailbox, but how then to explain the last half of the message? My host would never see the tail end of the last message since it started copying the file before the tail end was written. The /var/spool/mail host would write the tail end of the last message to the file it had open, but that file would disappear after my host deletes it (or zeros it out) after the copy. The next message would be delivered to an emtpy file, and the tail end of the message which my host missed would end up in the bit bucket. My intuition tells me that the problem is not in the copying of the mailbox from /var/spool/mail to ~/evolution/local/Inbox, but in the process that picks apart the copy of the mailbox under ~/evolution/local/Inbox. But I have no hard data to prove it. -norm -- Norman Joseph, System Engineer [EMAIL PROTECTED] IC|XC Concurrent Technologies Corporation 814/269.2633 --+-- Federal Systems Group/IT & Systems Engineering NI|KA *** Be kind, for everyone you meet is fighting a great battle *** _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
