GNOME Bugzilla – Bug 621765
imapx issues STATUS for currently-selected mailbox
Last modified: 2015-08-07 06:34:53 UTC
adding command, fmt = 'STATUS %f (MESSAGES UNSEEN)' got folder 'lists/arm' completing command buffer is [36] 'STATUS "lists.arm" (MESSAGES UNSEEN)' enqueue job 'STATUS "lists.arm" (MESSAGES UNSEEN)' ** Starting next command - we're selected on 'lists/arm', current jobs? -- Checking job queue -- 0 'STATUS'? --> starting 'STATUS' Staring command (active=1,) A02870 STATUS "lists.arm" (MESSAGES UNSEEN) camel_imapx_write: 'A02870 STATUS "lists.arm" (MESSAGES UNSEEN) ' ** Starting next command * no, no jobs camel_imapx_read: buffer is '* STATUS "lists.arm" (MESSAGES 16417 UNSEEN 16315) A02870 OK [CLIENTBUG] Status on selected mailbox completed. '
see patch in https://bugzilla.gnome.org/show_bug.cgi?id=621842#c1
Created attachment 163948 [details] [review] refresh-info rewrite in progress Hm, it's fuckeder than that. We issue a NOOP on the folder first, even if the folder wasn't selected in the first place and we have IDLE support. So it's always selected by the time we get round to issuing STATUS. This is an attempt at sorting it out. In a separate commit I already implemented HIGHESTMODSEQ support, which helps.
Created attachment 163970 [details] [review] rewrite-me-harder There's no need for imapx_job_refresh_info_start() to bother about fetching new messages -- that'll happen from imapx_job_scan_changes_done() anyway. Make a better attempt to keep track of the unseen count as well as uidnext and modseq (for CONDSTORE-enabled servers). Try to simplify the logic deciding when to rescan. Don't issue STATUS on the selected folder, ever -- use NOOP instead, and accept that the modseq may be wrong (but the folder selected so we ought to have been told of any changes anyway). This runs on my nice shiny Dovecot server with CONDSTORE (and I'll be exploring more of the Lemonade stuff too), and it runs on my crappy Microsoft Exchange server which supports fairly much nothing useful.
http://git.infradead.org/users/dwmw2/evolution-data-server.git/commitdiff/677aa785 This makes it store the UIDNEXT and MODSEQ information in the summary cache, so on a CONDSTORE-capable server you can skip the initial fetch at startup. I should actually be using CHANGEDSINCE, but I'll get to that...
Any idea if these patches are still relevant? I did some refactoring on the IMAP code last fall, but even still there's work yet to be done around mailbox synchronization. Even when using QRESYNC I notice it still likes to refetch all the message flags when selecting a mailbox. Don't really have my head around that part yet. I think I have STATUS results under control now at least.
Review of attachment 163970 [details] [review]: The patch is outdated these days. it also may not enable extra debugging. If it's still relevant, please update the patch for current git master.
*** Bug 747459 has been marked as a duplicate of this bug. ***
So I did actually implement the logic in this patch and commit it. But then later disabled it (and it's still there with #if 0 around it): https://git.gnome.org/browse/evolution-data-server/commit/?id=b44f64b984
Fixed within bug #745545, I'm closing this.