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