On Sun, Aug 22, 2021 at 12:55:49PM +0200, Pieter-Tjerk de Boer via Mutt-dev wrote:
On Sat, Aug 21, 2021 at 12:50:20PM -0700, Kevin J. McCarthy wrote:This was observed in Trac ticket 3942: <https://gitlab.com/muttmua/trac-tickets/-/blob/master/tickets/closed/3942-mutt_with_hanging_on_large_Exchange_Deleted_Messages_folder.txt>Ouch, that seems a rather severely broken IMAP server implementation then. The assumption, made by mutt and discussed in that ticket, namely that the MSNs are consecutive and can't exceed the message count, is in fact well supported by the RFC: not just by the sentence I quoted but also by the further examples given in that RFC.
I agree the server wasn't behaving nicely. It simply omitted some of the headers. (Probably they were deleted at some point between the "assembly" of the mailbox on its side and sending all the headers - the mailbox was very large and changing constantly I think.) However the MSNs didn't repeat or exceed the initial max MSN reported, so I think it might be debatable if it was broken.
Well, as a user, I would expect 'unsorted' to match the order the messages have on the IMAP server. This is practically useful, as it ensures that the latest additions to the mailbox are all together at the end. Could we solve this by applying my previous patch, and adding a check at the end that the index values (derived from MSN as per my patch) are in fact consecutive, and modifying them as needed?
I wouldn't be willing to do this for these stable branch fixes. I'd have to think about it for master. My inclination is to leave the index separate from MSN. The mis-order is not an ordinary situation, so I don't think it's worth reintroducing the complication for this case.
On Sat, Aug 21, 2021 at 01:21:37PM -0700, Kevin J. McCarthy wrote:I've pushed up two commits to branch kevin/stable-imap-header-cache-hole on gitlab. <https://gitlab.com/muttmua/mutt/-/commits/kevin/stable-imap-header-cache-hole>. The first is your msn_begin fix commit and the second is a currently untested commit changing the sort order before generating msgset strings.Nice! For what it's worth, I tested it the same way as I tested my own earlier patch (triggering the bug by temporarily making the IMAP server unreachable), and it works okay in that case.
Thank you for testing the fixes. I'm going to test and look at it some more the next few days, but will get a stable release out with these fixes this week.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
