On Thu, 2007-05-24 at 16:08 +0300, Timo Sirainen wrote: > On Thu, 2007-05-24 at 16:03 +0300, Timo Sirainen wrote: > > > Or should dovecot be not relying on cached state and revalidate the > > > mailbox on STATUS, even if it is already SELECTED? > > > > Dovecot checks if new/ or cur/ directory's mtime changed. If neither > > did, it trusts its cached state (basically, there's another > > dirty-recheck-rule). > > Ah, right. I tested it immediately after replying and looks like STATUS > for a selected mailbox is a bit special. It doesn't synchronize the > mailbox before or after the lookup. I'm not sure if there's a reason for > this, but this most likely won't get fixed for v1.0.x.
Sorry for the mail flood :) So the above means that Dovecot replies with
STATUS the current known mailbox state. So for example "NOOP + STATUS"
will reply the latest changes, but simply doing STATUS won't change
anything. I'm not sure what your original example about EXPUNGE + STATUS
meant, because that should have shown the current state after the
EXPUNGE.
And then some choice quotes from RFC 3501:
It does not change the currently selected mailbox, nor does it
affect the state of any messages in the queried mailbox (in
particular, STATUS MUST NOT cause messages to lose the \Recent
flag).
This is probably why Dovecot doesn't synchronize the mailbox.
Synchronizing it would lose the \Recent flags. Although this probably
wasn't intentional when writing the above, I think it would still be
wrong for server to do that. It's a pretty clear MUST NOT there.
Note: The STATUS command is intended to access the
status of mailboxes other than the currently selected
mailbox. Because the STATUS command can cause the
mailbox to be opened internally, and because this
information is available by other means on the selected
mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox.
Right. What I said. You don't need it.
The STATUS command MUST NOT be used as a "check for new
messages in the selected mailbox" operation (refer to
sections 7, 7.3.1, and 7.3.2 for more information about
the proper method for new message checking).
So gnus is breaking a "MUST NOT" from the RFC.
signature.asc
Description: This is a digitally signed message part
