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 ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
