Re: gnus/nnimap behaviour in case of failed fetch operations

[Simon Josefsson <jas@extundo.com>]

Uli Wortmann <uli.wortmann@utoronto.ca> writes:

> Hi Simon, 
>
> ok, first of all I have a couple of details on the server. Might be
> interesting for others too. The problem is clearly related to
> Microsofts Exchange Server with applied servicepack II. In this
> configuration the server will produce 
>
>       Unrecognized internal error: 0xfffffae2
>
> which shows up in the internal mailserver logs too. This is unrelated
> to the client side, and happens with outlook or the outlook
> web-interface as well.  In the meantime, there is patch for SPII
> correcting this problem.

Ok.  So the fix is probably to apply the patch.

>     > The unread count in the group buffer is just a guess, it is
>     > normal for it to show 20 when you only have 19 unread.  It
>     > happens if some article is deleted or the server just felt like
>     > jumping in the UID range.
>
> yes I know. That's exactly why the problem slipped my consciousness
> for so long. I got suspicious because  expected mails did not show
> up. Thus I used the function "show old mails", which actually showed
> all missing mails, but marked as old-mails.
>
> The relevant part of the imap-log is
>
>          313 OK SEARCH completed.
>          314 UID FETCH 1905 BODY.PEEK[]
>          314 NO Unrecognized internal error: 0xfffffae2
>
> after that error, UID 1905 gets marked either as old, if the header
> fetch failed, or as permanently deleted if the body fetch failed.

Yes, Gnus marks non-existings articles as read.  This goes back to
nntp, where it is not uncommon for the server to forget an article for
some reason or other.  Gnus regards it as non-existing and moves on.

I can't really come up with an approach that is better.  What IS gnus
supposed to do if there it can't fetch an article with a certain UID?
Simply ignoring that UID seems like the best we can do.