[Dovecot] 1.0-stable loses flag changes sometimes?

[Chris Wakelin]

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
> 1) There have been several recent deliveries
> 2) Possibly some of those deliveries are of multiple messages
> 3) Possibly they are read very quickly (say only a second for each 
> message)
> 4) 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 at 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 at 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