An example of an nnimap group where the Group count is always wrong

An example of an nnimap group where the Group count is always wrong

[James Cloos]

I noticed this with one of my nnimap groups which always gets wrong info
in Group.

Everytime I run g or M-g this group shows seven unread articles in its
Group count, but selecting it always says zero unread articles.

As you can see, even though SELECT shows zero exist and zero recent, and
even though UID FETCH 1:* FLAGS shows no articles, gnus is convinced that
uids 29 through 35 exist.

This is from repeated M-g and SPACE:

read(0, "103351 SELECT \"dsnp-interest@complang.org\"\r\n"
write(5, "* 0 EXISTS\r\n"
write(5, "* 0 RECENT\r\n"
write(5, "* FLAGS (\\Seen \\Answered \\Deleted \\Flagged \\Draft)\r\n"
write(5, "* OK [PERMANENTFLAGS (\\Seen \\Answered \\Deleted \\Flagged \\Draft)]\r\n"
write(5, "* OK [UIDNEXT 0] Predicted next UID\r\n"
write(5, "* OK [UIDVALIDITY 41557] UID value\r\n"
write(5, "103351 OK [READ-WRITE] SELECT completed\r\n"
read(0, "103352 UID FETCH 1:* FLAGS\r\n"
write(5, "103352 OK UID FETCH completed\r\n"

read(0, "103353 UID FETCH 29:35 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])\r\n"
write(5, "103353 OK UID FETCH completed\r\n"

read(0, "103354 SELECT \"dsnp-interest@complang.org\"\r\n"
write(5, "* 0 EXISTS\r\n"
write(5, "* 0 RECENT\r\n"
write(5, "* FLAGS (\\Seen \\Answered \\Deleted \\Flagged \\Draft)\r\n"
write(5, "* OK [PERMANENTFLAGS (\\Seen \\Answered \\Deleted \\Flagged \\Draft)]\r\n"
write(5, "* OK [UIDNEXT 0] Predicted next UID\r\n"
write(5, "* OK [UIDVALIDITY 41557] UID value\r\n"
write(5, "103354 OK [READ-WRITE] SELECT completed\r\n"
read(0, "103355 UID FETCH 1:* FLAGS\r\n"
write(5, "103355 OK UID FETCH completed\r\n"

read(0, "103356 UID FETCH 29:35 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])\r\n"
write(5, "103356 OK UID FETCH completed\r\n"


The info in .newsrc.eld for that group is:

  ("nnimap+l:dsnp-interest@complang.org" (55 . 24) nil
   ((seen (7 . 35)) (cache 34)) "nnimap:l"
   ((modseq) (uidvalidity . "41557") (active 29 . 35) (permanent-flags %Seen %Answered %Deleted %Flagged %Draft) (timestamp 19864 55661) (imap-status . "0 1 0")))


Art 34 does exist in ~/News/cache as claimed in newsrc.  And is the only
art there.

The Group buffer has been broken ever since the support for syncing to
the imap server was added.  Immediately before that it worked perfectly.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[CORRECTED] Re: An example of an nnimap group where the Group count is always wrong

[James Cloos]

[SIGH]

<Brown_Paper_Bag_Mode>

Why is it that it takes sending out a message to figure out a bug?

It seems that when I updated my patch set for dbmail (which initially
targetted uids-per-group) to make imap LIST efficient, I lost one line
of the original patch set dealing with UIDNEXT.

With that one-line patch reinstated, my Group buffer is correct again.

I wish I had noticed the inaccurate uidnext value in the last email
before hitting C-c C-c....

</Brown_Paper_Bag_Mode>

[SIGH]

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6