All,
I found the problem and have completed the fix. Essentially what was happening is that the "SORT" command to the IMAP server would return the message sequence numbers in the correctly sorted order. RC would then perform a "FETCH" command to get the message header data, using the ordered sequence numbers that came back from the SORT. Unfortunately, the IMAP server is free to ignore the order of the sequence numbers provided in the FETCH command (see RFC 3501 §9, "sequence-set"), so it was returning the headers in ascending sequence number order (ignoring the sorted order). The subsequent RC code assumed that the FETCH command returned the messages in the requested order, causing the incorrect order in the display.
I may have overengineered the fix, but I haven't noticed any performance hit at all. I put the patch at:
http://stadtherr.bounceme.net/files/rc_sort_fix.patch
Someone will have to let me know how best to get the fix incorporated (I don't have SVN access).
Enjoy!
-Eric
PS. I haven't tested it with caching turned on, since I like to leave that off If someone has caching enabled and wants to test this, can you let me know how it works?
On Mon, 24 Jul 2006 22:44:46 -0600, Eric Stadtherr wrote:
I found the problem and I have a patch almost ready. My fix is working for small folders but it doesn't handle multi-page message lists yet. I'll post it as soon as it's done!
-Eric
Eric Stadtherr wrote:I did some digging into this issue over the weekend, and discovered that rcube_imap::_list_headers is getting a correctly sorted list of message UIDs back from iil_C_Sort(). This means that the sorting within the IMAP server (mine is dovecot) is being done correctly, but RC is still displaying them in an incorrect order (the order of UIDs in the display table doesn't match the order of UIDs that come back from iil_C_Sort(). I didn't get a chance to trace it any further through rcube_imap::_fetch_headers and out through the display code.
On Mon, 24 Jul 2006 09:49:23 -0700, Mark Edwards wrote:
On Jul 24, 2006, at 9:17 AM, Jim Pingle wrote:
> There appears to be support for a similar option in the code for
> roundcube
> (in imap.inc), but I see no method for a user/admin to set it. In
> rcube_imap.inc it's explicitly set off, but at the start of
> imap.inc it is
> set on. It tests to see if IMAP_USE_HEADER_DATE is false which it
> always
> will be as I can't find any other reference to the variable it's
> testing for
> anywhere in the code.
>
> As an experiment you could try commenting out line 57 in program/
> lib/imap.inc:
> if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
>
> Alternately, change that so it's set to false instead of true.
>
> If it alters the sorting behavior for you, we may have found the
> culprit...
Unfortunately, that did nothing. :-(
Squirrelmail get the sort right on this particular mailbox, whether
server-side sorting is enabled or not. Roundcube puts a bunch of old
mails out of order at the top of the box.
--
Mark Edwards