I'm still struggling with this (and at least one other colleague has the same issue).
I've tried 1.0-test69 to see if it was just a 1.0-stable issue, but that seems worse!
E.g. Here's a (telnet) session to 1.0-test69. There are no other clients connected. While the client is idling, three messages are appended at once, and for some reason Dovecot gives some spurious untagged FETCH responses. If I append three more messages, three more spurious responses come, with UIDs 684,685 and 686.
. SELECT INBOX
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
- 705 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1111502437] UIDs valid
- OK [UIDNEXT 24787] Predicted next UID . OK [READ-WRITE] Select completed. . IDLE
- idling
- 681 FETCH (FLAGS (\Seen))
- 682 FETCH (FLAGS (\Seen))
- 683 FETCH (FLAGS (\Seen))
- 708 EXISTS
- 3 RECENT DONE . OK Idle completed.
It seems similar to the 1.0-stable issue, only the spurious FETCH responses seem to give the wrong flags then (but I can't reproduce this on demand).
I should say, I didn't see this problem with 1.0-stable releases before 21st April, so it looks like those "large mbox code cleanups" may be the cause.
I wondered whether this may be another issue related to the UW-IMAP pseudo-message, so I removed that from my INBOX, but I'm still seeing the problem.
I've had a go at trying to understand the mbox sync code, but without much success yet ;)
Best Wishes, Chris
Chris Wakelin wrote:
I've been struggling with an odd bug in the latest 1.0-stable (20050427) release. Sometimes Dovecot seems to forget that a message has been read or deleted and marks it unread (or not deleted).
As far as I've been able to determine, it seems to happen when
- There have been several recent deliveries
- Possibly some of those deliveries are of multiple messages
- Possibly they are read very quickly (say only a second for each message)
- Folder is an mbox (haven't tried Maildir)
I've seen it with Thunderbird mostly, but did manage to recreate it once in "telnet" - the debug IMAP client ;) - using "IDLE" "FETCH" and "STORE msgid +FLAGS (\Seen)" commands.
I managed to catch it in the act with one Thunderbird session, and it seemed to occur when Thunderbird, for some reason, issued an IMAP "CHECK" command. In this case it issued an extra "* 710 FETCH (FLAGS (\Recent))" response (the new messages had been msgid 711-715).
Incidentally, Thunderbird seems to do a "STORE .. +FLAGS (\Seen)" command even though this is implicit the "FETCH .. BODY[..]" command (and it gets informed of the flag change in the response).
I've tried and tried to find a "formula" for re-creating the problem "on demand", but it only goes wrong occassionaly.
My guess is it's some sort of timing thing with mbox sync (BTW we have "mbox_dirty_syncs = yes" and "mbox_very_dirty_syncs = no").
Has anybody else seen this?
I'm hoping to roll out this version to our wider group of testers soon and would like to get this issue solved first if possible (it counts as an annoyance rather than a serious problem).
Best Wishes, Chris
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094