https://bugs.kde.org/show_bug.cgi?id=338186
--- Comment #34 from Marcel Naziri <zwo...@fsfe.org> --- (In reply to Christian Mollekopf from comment #27) > > So kdepim-runtime seems to be affected. RetrieveItemsTask::onFinalSelectDone > > gets -1 values for nextUid which are not correctly mapped to an IMAP > > interval like 1:* instead it results in 1:-1 > > That does sound like a server bug, or at least I don't know when UIDNEXT < 0 > would make any sense. As you can see in the formerly attached log the Courier imap server does not give a nextuid prediction, so the value -1 comes from the default value of SelectJob. I don't know if Courier breaks any rules not to answer with UIDNEXT. > I suppose we can catch this case and just fallback a very large UIDNEXT > value. I made a quick patch to set the nextuid value to 0 in RetrieveItemsTask::onFinalSelectDone in case it's set to -1 before the FetchJob is build. This way the ImapInterval will result not in "1:-1" but in "1:*". According to RFC 3501 "*" represents the largest number in use. This way the sync with kdepim 4.14 and Courier worked again. I hope this gives a good starting point for a proper fix. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs