UIDPLUS unordered support

[alexobenauer]

If I'm completely missing something, or simply wrong, just let me know.

In my testing, it seems that Gmail does not copy messages in the same order that they were in, by UID, in the original folder. (For what it's worth, I also tested on FastMail, which seemed to copy in order). It does, however, return the unordered UID's in the order that matches the original sorted order of the UID's sent:

event logged: 0 withData: 13 OK [COPYUID 658824223 33630,33650:33651,33653 2273,2275,2274,2272] (Success)

Where 33630 -> 2273; 33650 -> 2275; 33651 -> 2274; 33653 -> 2272

But these destination UIDs are returned in MCOIndexSet, so the order given by Gmail cannot be determined.

Is there something I'm missing, or a way to determine their order currently? Or would a fix, such as using an array instead of an index set, be needed?

[dinhvh]

Very true. It really needs to be fixed.
It would also be a breaking change so it needs to be fixed sooner rather than later.
NSDictionary would probably be easier to use.

[dinhvh]

I committed a fix f5514d6: Could you try it?
Thanks!

[alexobenauer]

Wow - you're fast. Thanks for taking a look at this. And I agree - an NSDictionary would definitely be ideal.

I was getting some weird results, such as duplicate destination UID's, or not all UID's being returned:

Let me know if this simply isn't how it works; but I believe the problem is here:

mailcore2/src/core/imap/MCIMAPSession.cc

Line 1614 in f5514d6

dest_current_uid ++;

It is assumed that the ranges of dest_cur match the ranges of src_cur. But since dest_cur comes in out of order, it would be easy for this scenario to occur:

src_cur = 1:3
dest_cur = 23,21,22

Expected: 1->23; 2->21; 3->22
Result: 1->23; 2->24; 3->25
Because L1614 simply increments dest_current_uid even though its range is over.

Or:

src_cur = 4,6,8
dest_cur = 22:23,21

Expected: 4->22; 6->23; 8->21
Result: 4->22; 6->21; (nothing provided for 8, as dest_cur goes null)
Because L1617 skips to the next dest_cur range even though its range is not over.

Since the ranges may be different, should they be unrolled independently, then paired up? If I'm completely mistaken, let me know!

[alexobenauer]

This could do it, unless there's a reason arrayFromSet() was pulled?

Array *src_arr = arrayFromSet(src_uid);
Array *dest_arr = arrayFromSet(dest_uid);

for (int x = 0; x < src_arr->count() && x < dest_arr->count(); x++)
{
    uidMapping->setObjectForKey(src_arr->objectAtIndex(x), dest_arr->objectAtIndex(x));
}

[dinhvh]

Thanks for the suggestion. It also really simplifies the code.

[dinhvh]

Also, feel free to send pull requests ;)

[alexobenauer]

Fantastic, no problem. Thanks again for looking into this.

And on pull requests: Will do. I was going to submit a request for that tonight if you hadn't seen it by then. I'll be better about submitting requests in the future!

[dinhvh]

I already applied the fix. Then, it's ready to test.

[dinhvh]

Could you let me know if it's working properly now?
Thanks!