Thomas,

That's essentially what I did in my fix - use the sequence returned by the IMAP SORT command to re-order the list returned by the FETCH command.

The only problem with using iil_SortHeaders to sort the fetched list is that it implements its own sorting algorithm, ignoring the sequence returned by the SORT command. The algorithm probably produces the same results, but why tell the IMAP server to sort the list and then throw away the results? I think we need to choose one or the other - tell the IMAP server to sort the list, or execute our own sorting algorithm. I vote for letting the IMAP server do the sort - this automatically gives us support for any future IMAP sorting behavior without having to maintain our own algorithms.

 Thoughts?

 

On Wed, 26 Jul 2006 09:23:16 +0200, "Thomas Bruederli" wrote:

Hi,

Actually RoundCube should attempt to sort the message set retrieved
from the server again because you can't be sure that the messages are
returned in the right sequence. This is done in rcube_imap.inc on line
571/572 but those lines were commented out in revision 203 by myself
(shame on me!). Making use of iil_SortHeaders() again should solve the
problem. If not, we should try to improve the sorting algorithm in
that function.

Regards,
Thomas


2006/7/26, Eric Stadtherr :
>
> 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
>>