Re: Updated IMAP unread count correction

[Dave Abrahams <dave@boostpro.com>]

on Sun Jun 10 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> It won't do any good at all to run that code unless I can get it to
>> report the right number, so that I'll notice when it reports the wrong
>> one.  If you can tell me how to get things back in sync, I can try
>> running the normal code again.  
>
> (gnus-clean-old-newsrc t) and then `g'.

OK, I'll try that out later today.

>> [Incidentally, one thing I dearly wish for in Gnus is the ability to say
>> "throw out all the information you have that can be derived from the
>> server (and re-derive it on demand)."
>
> `M-g' on each group will do that.

That couldn't possibly fix things like incorrect information in the
agent, the gnus cache, and the registry, could it?  What use would those
stores be if they disappeared the moment you hit `M-g'?

>> I don't know if it helps, but I am using a local dovecot with
>> offlineimap and recently had to rebuild the local mailstore.  Thus the
>> UIDs of messages on the server could easily have been changed.
>
> Gnus should detect that and do a full rescan.  Unless the IMAP server
> doesn't change its UIDVALIDITY...

I don't know what that is, but FWIW, I did a fresh rebuild / reinstall
of dovecot to get to this point.

>>> `G E' on a group will show you what messages Gnus thinks don't exist on
>>> the server.  (In the `unexist' list.)  If that gets out of sync,
>>> something wrong happened.
>>
>> `G E' on my INBOX currently shows more than 800 "seen" entries and about
>> 3 in the unexist list.  There are only 3 messages actually existing in
>> that mailbox.  Not sure what that tells you, though.
>
> It tells me that your .newsrc.eld data is messed up.  :-) But not much
> more.

Right.  It would be awesome if Gnus could implement some optional
internal checks for such data getting out-of-sync.  I'd be willing to
run with such checks on for a couple weeks, even if it slowed Gnus down,
if it would help us track down some of these issues.

BTW, the need to `C-g' to get out of apparently-hung nntp server
connections is still de rigeur for me.  If that is liable to mess up
Gnus' state, maybe we could do something to make that more reliable?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com