Re: gnus-agent-fetch-selected-article

[kgreiner@xpediantsolutions.com]

[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]

David S Goldberg <david.goldberg6@verizon.net> writes:

>>>>>> On Tue, 07 Jan 2003 23:22:13 -0600, kgreiner@xpediantsolutions.com said:
>> David, please make a backup of your group's .overview and .agentview
>> files before executing gnus-agent-regenerate-group.  You should then
>> be able to compare the old/new versions to see what regenerate
>> changed.  If you can tell me what regenerate is fixing, it may help me
>> understand what is breaking.
>
> OK, I repeated the problem by running expiry.  

Is this group expiration or agent expiration?

>
> Verified that the two new messages in my inbox were not available.
>
> Exited the group with Q.
>
> Backed up .overview and .agentview to .{over,agent}view.before.  
>
> Ran gnus-agent-regenerate. The overview file didn't change.  The
> .agentview file was cut in half.  I copied it to .agentview.after for
> posterity.
>
> Re-entered the group to verify that I could now see the new articles.
> I could.
>
> Started writing this message to which I'm attaching the
> .agentview.before and .agentview.after (they are quite small).
>

Dave,

Thanks for the files.  I uncompressed the alist in each file then
diff'ed the results.

First a little background (it helps me keep all of this straight), the
alist consists of entries in the form (n . m) where n is an article
number as m is the day on which the article's body was fetched.  If an
article header was fetched, but never its body, the entry will look
like (n).

Regeneration first repairs the overview file by
1) Sorting it by ascending article #
2) Removing duplicate articles
3) Inserting missing entries by extracting the headers from the fetched
   article's body.

It then rebuilds the group's article alist to match the overview and
fetched article files.

In your case, regeneration did the following.

1) You had 1759 entries looking like (n).  All but ten of these
   entries were deleted.
2) An entry was added for article 12414.  The article body has been
   fetched.
3) An entry for article 414 was deleted.  The only significance is
   that the agent thought that this article's body had been fetched.

The first item implies that the nnimap backend tried to fetch nearly
1800 headers but failed on nearly every one.  That would result in (n)
entries in the .agentview that are not matched to NOV entries in the
.overview.  While inefficient, no harm should have resulted.

Could the second and third be the result of moving an article?  Is
there any significance to the 414 appearing within 12414?

Could the nnimap backend be re-using article numbers?  If so, that
would explain everything.

If you don't mind, I'm really appreciate more assistence.

Please make the following configuration changes.
1) Set gnus-verbose to 10.
2) Set message-log-max to 10000
3) If it doesn't already, edit your gnus-summary-line-format to
   include the %N format.  This will result in the article number
   appearing in the summary.

Then test as follows
1) Execute (gnus)
2) load the attached file.
3) Open the group that is giving you trouble.  If it doesn't display
   correctly, close it and run regenerate.
4) Open the group again.  If you check *messages*, you should see that
   fetch-headers had no undownloaded headers to fetch.
5) Close the group.
6) Do something to break the group.
7) Open the group again and execute '/ N' to load new messages.  Did
   they appear? Repeat until you get the bug to appear.
8) Close the group, turn off the agent, then reopen the group. 

I'd like a copy of the *message* buffer.  I'd also like you to
identify the article # of the new article(s) that had not appeared due
to the agent.  You can sanitize the message log of all names if it
matters to you.  All I need are the article numbers.

Thanks,
Kevin

[-- Attachment #2: Debug code --]
[-- Type: application/emacs-lisp, Size: 4973 bytes --]