On Sat, Jul 18, 2009 at 09:25:48AM +0930, Ron wrote: > On Fri, Jul 17, 2009 at 05:35:26PM -0400, Timo Sirainen wrote: > > Can you try if you can easily reproduce this > > using imaptest tool on a test account? http://imapwiki.org/ImapTest > > No, that doesn't reproduce it at all. I ran: > ./imaptest host=pat port=14300 user=ron pass=word > > through stunnel as there is only imaps there, and after letting it do > its thing for quite some time there were none of the corruption messages. > > Curiously it does seem to freak mutt out. If I have a mutt instance open > to the inbox that imaptest is scribbling over and do an <imap-fetch-mail> > in it after imaptest has started, it shows no messages in the box at all. > Re-opening the inbox shows what currently remains in there though. > > So here's what I can do to reproduce it, confirmed again after the last > imaptest run: > > 1. Start 2 instances of mutt into the same imap folder. > 2. echo "hmm" | mail -s test ron > 3. <imap-fetch-mail> in one of the mutt instances to update the index > of what is in the mailbox. > 4. Open the new message in it. > > Then the corruption message appears in the logs. It's not 100% sure > to happen, but I think when it doesn't it's because I've done the above > in the mutt instance that currently 'owns' the most recent version of > the 'corrupted' data. There's a 50/50 chance or better of this > triggering it though, so it's not a _really_ obscure race we are losing. > Mostly it just seems that something isn't syncing when it should ...
I guess I should also mention that postfix is delivering the mail to dovecot with: mailbox_delivery_lock = fcntl, dotlock mailbox_command = /usr/lib/dovecot/deliver -a "$RECIPIENT" -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
