On Sun, Jul 19, 2009 at 02:14:17PM -0400, Timo Sirainen wrote: > On Jul 17, 2009, at 9:04 PM, Ron wrote: > > >>>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. > >> > >>So 3 and 4 are on the same mutt instance, and the second mutt > >>instance > >>haven't even see the mail yet by the time the corruption happens? > > > >Yes, that's correct. In the last few tests I did, the second instance > >wasn't yet aware of the new mail at the time I opened it in the first. > > The 4. step seems a bit strange to me. I'd think 3. would have been > enough to cause it. Since 3. is where it reads/writes cache file. In > 4. step is also reads it, but.. strange if it just worked in 3 but > was broken in 4..
Ok, so it looks like the two mutt instances thing was something of a red-herring. I've since seen these same warnings with only a single mutt instance active ... > Anyway, I just dist-upgraded my debian unstable yesterday and tried > with its mutt and couldn't reproduce this. However I've also now had trouble reproducing it with the same incantation myself too. They hadn't gone away, but there seems to be more to it than just doing that, some other bogus state needs to be entered first apparently ... I've also been seeing mail that was flagged as 'old' but unread triggering "new mail" alerts, but again somewhat at random, and only for particular messages. That running the imaptest totally confused mutt about the state of the mailbox also seemed suspicious. > >mail_location: mbox:~/Mail:INBOX=~/Mail/inbox > >mbox_write_locks: fcntl dotlock > >mail_plugins: antispam > > Can you try if you can reproduce it without antispam? > > > sieve_global_path: /etc/dovecot/sieve/default.sieve > > And also what if you have Sieve disabled with deliver? Or if you let > Postfix write the mail instead of using deliver? Both these systems have gone live now, so I can't fiddle with them quite as much as I could a few days ago -- however that's not been without its own clues. I'm not seeing any of these triggered by the thunderbird users, and combined with your results, that leaves me suspecting something in my muttrc. It's not terribly fancy, but things that looked interesting were: mail_check = 60 Which gives a bigger window for the two instances to get out of sync (but shouldn't matter is the server is doing the right thing). Also I have a fairly long list of 'mailboxes' on 3 separate servers which it's watching for new mail. But my prime suspect right now is 'imap_peek = no' ... I'd enabled that sometime back because a crackful cyrus server would continually leave a whole bunch of my incoming mail marked unread 'at random', no matter how hard I tried to force a sync with it, and every time I'd restart the client I'd have to sort through huge chunks of all my old mail that was 'new' again... This did fix that there. It's still a little bit early to hoist the mission accomplished banner, but since I've set that back to 'yes', I haven't seen these warnings again yet. So I figured I'll tempt the fates and pass that along now. They've been happening often enough that if I see none tomorrow, we can probably be pretty sure, and in the meantime it might give you the clue you need for it all to make sense as either a dovecot bug, or another "don't do that" thing in mutt :) If I do see them, I'll find another machine to set up a test server on and try to rule out the plugins, but so far all signs are pointing at trouble with mutt specifically, whatever it may be tickling on the server side ... and I'm quietly confident right now that the peek setting is up to its neck in this. Cheers, Ron -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
