From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/579 Path: news.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.user Subject: Re: gnus/nnimap behaviour in case of failed fetch operations Date: Wed, 05 Jun 2002 17:31:36 +0200 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138667531 7510 80.91.229.2 (31 Jan 2006 00:32:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2006 00:32:11 +0000 (UTC) Original-X-From: nobody Tue Jan 17 17:27:48 2006 Original-Path: quimby.gnus.org!not-for-mail Original-Newsgroups: gnu.emacs.gnus Original-NNTP-Posting-Host: 178.230.13.217.in-addr.dgcsystems.net Original-X-Trace: quimby.gnus.org 1023292383 31272 217.13.230.178 (5 Jun 2002 15:53:03 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 5 Jun 2002 15:53:03 GMT User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) Cancel-Lock: sha1:hcrOfoVQotiNmXcdlhti0n36y3Y= Original-Xref: bridgekeeper.physik.uni-ulm.de gnus-emacs-gnus:719 Original-Lines: 44 X-Gnus-Article-Number: 719 Tue Jan 17 17:27:48 2006 Xref: news.gmane.org gmane.emacs.gnus.user:579 Archived-At: Uli Wortmann 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.