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

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

[Simon Josefsson]

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.

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

[those who know me have no need of my name]

in gnu.emacs.gnus i read:

>those who know me have no need of my name <not-a-real-address@usa.net>
>writes:
>> in gnu.emacs.gnus i read:

>>>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.
>>
>> and is unfortunately inappropriate behavior, sometimes.
>
>What would a better behaviour be?  I can't really see anything else to
>do.  Retrieving the article didn't work, so the article doesn't exist.

i'm not sure what would be better, in the context of gnus, but the article
may yet appear.  server farms often experience this sort of thing, and
other newsreaders have made allowances for it (i.e., agent's `server
creates articles out of order' setting); overview records can be available
or article numbers consumed before the article itself is available.  the
same sort of behavior cannot (or at least should not) happen to imap
servers, but the root of the problem is how gnus reacts not how nnimap
reacts.

-- 
bringing you boring signatures for 17 years