On Sat, Aug 21, 2021 at 12:50:20PM -0700, Kevin J. McCarthy wrote: > On Sat, Aug 21, 2021 at 09:32:11PM +0200, Pieter-Tjerk de Boer via Mutt-dev > wrote:
> > in RFC3501, > > section 2.3.1.2, the MSN is described as "A relative position from 1 to > > the number of messages in the mailbox". This implies there can be no > > holes, or am I overlooking something? > > 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. > > But I think it wouldn't solve the problem that the unsuccesfully-deleted > > message jumps to a different position in the unsorted mailbox view. > > I understand, but I don't think unsorted makes a particular promise here. > It just reflects the messages as they are assembled into the index. 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? This check would only need to be done if an MSN has been seen that's larger than the message count. If you agree, I'd be willing to write the code for this, but I don't have a broken IMAP server to test against... 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. Regards, Pieter-Tjerk
