Greetings, We run a clustered student email system, using uw-imapd on the back-end for mailbox storage and retrieval. We recently expanded our storage for student accounts, which are held on a GFS file-system (RedHat GFS from CVS, circa May 2005). In the process of doing this, we upgraded our backend from a uw-imapd-2001 branch on RedHat 9 to uw-imapd-2004d on Debian Sarge (we are NOT using the Debian version of uw-imapd, since we require different compile flags).
It recently came to our attention that the messages being marked for deletion in users' mbx folders are shown to be expunged without error (we've run by-hand imapd connection tests), and subsequent reads on the mbx file show no existence of the "expunged" messages, but the data still remains in the file. Thus, the messages have become "lost" in the file, as far as the uw-imapd utilities know. It doesn't appear to be corruption of the file format, per se, since other non-expunged messages are still accessable to the users (as are new messages that arrive). The expunge is simply not removing the messages from the file. We have noticed that when the message is "expunged" but doesn't actually get deleted, the flags in the mbx header of the message changes as follows: Before expunge: 14-Jun-2005 15:54:53 -0500,1377;000000000003-00000048 After expunge: 14-Jun-2005 15:54:53 -0500,1377;000000008003-00000048 Once the new '8' flag is set, the message goes "invisible" to uw-imapd. We've run local filesystem tests in the exact same fashion as we have on the GFS filesystem. We can consistently and properly expunge messages from the mbx folders stored on the ext3 filesystem, without issue. We have not yet been able to do so on the GFS filesystem. We have also experienced trouble with tmail and locking under a clustered environment, which causes corruption of the mbx folder when two messages are delivered at the same time (common in a clustered environment), and have been working on that issue to near-fruition with another coworker who is very familiar with the uw-imapd source (who has unfortunately been called away on another project). This may be a related locking problem, depending on the expunge operation's steps, and we have not been able to research or otherwise discover a solution. Any assistance that can be rendered is very much appreciated. Thank you, Shaun Ferguson _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
