On Mon, 2004-06-28 at 17:28, Hauke Fath wrote:
Timo Sirainen wrote:
On Mon, 2004-06-28 at 13:07, Hauke Fath wrote:
x OK [READ-WRITE] Select completed.
So, not that then. Are any flag changes permanent? If you modify seen flag, is "Status: RO" header ever written in the mbox?
Where would I see that? In a telnet session? In the headers in the mailbox file?
Well, both would work with 0.99.10.6. Probably easier to check from mbox file itself. But if the problems didn't always happen, I guess that's not the problem itself.
There are actually two problems that are reported to me:
(1) People are reading mail, and when the next mail comes in, the mails just read change status to 'unread'. I've seen this myself with a variety of clients, not strictly reproducibly, but... it happens.
Seeing what Dovecot and IMAP clients talk when it happens would help.. Enabling rawlog (last chapter in http://dovecot.org/bugreport.html) would do that.
One explanation would be that Dovecot sees the new mails (or that mbox has changed), then syncs the whole file again, but for some reason the UIDs don't match in right order, or some other data didn't match right, so Dovecot expunges those messages and creates new UIDs for them, forgetting about the old flag changes which wheren't yet written to disk. For example some older MUAs used to sort mbox, if Dovecot's X-UID header ordering was changed it generated new ones.
(2) People move read mail from the inbox to some other folder (or delete it) and find two copies - one in the new folder (or trash), and one in the old one. This I have not seen myself, and those who have seen it have not yet reported it for 0.99.10.6.
Could be the same problem.. Dovecot moves the mails, then tries to expunge the messages only to find out they were already gone.
I'd almost suggest trying 1.0-tests, but I guess they still have some problems too which might just make things worse (corrupt the mboxes), although I've been running them fine for a week or so..