Re: gnus-agent-fetch-selected-article

[David S Goldberg <david.goldberg6@verizon.net>]

>>>>> On Thu, 09 Jan 2003 16:48:18 -0600, kgreiner@xpediantsolutions.com said:
>> OK, I repeated the problem by running expiry.  

> Is this group expiration or agent expiration?

I do C-c M-C-x in the *Group* buffer, which I assume is group
expiration (somehow I thought I recalled agent expiration being rolled
into that, but I guess not).

> [...]
> 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.

That's bizarre.  I have some big gaps in there, but that number hasn't
been seen for ages.

> 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.

I keep meaning to B-m everything back into the same group to compress
the range but never seem to think of it when I'm actually working in
gnus :-)

> Could the second and third be the result of moving an article?  Is

12414 is actually a pretty old article that is kept around with a tick
(I have several tens of those).  It was created long before the
current gnus-agent code.  I happened to need to refer to it, hence it
was downloaded.

> there any significance to the 414 appearing within 12414?

Maybe, since article 414 went away a long time ago.  Certainly long
before 12414 was even created.

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

I doubt it.  I checked with my mail admin (it's good to be his boss,
response to questions is usually very good :-) and as far as he could
tell, cyrus uses monotonically increasing numbers though there's
probably a point at which it would loop back to something small.  I
didn't ask him to check the cyrus source to see where, though.

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

> Please make the following configuration changes.
> 1) Set gnus-verbose to 10.

Been done for a while :-)

> 2) Set message-log-max to 10000

This is log-message-max-size in XEmacs and it's default is 50000.

> 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.

Already there.  I need them for a utility function I wrote for easily
attaching messages.

> 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.

OK, I did all that.  I'm sending you the message log under separate
cover.  It's not huge, but big enough that I'm not sure the rest of
the list wants to be burdened with it.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net