David S Goldberg writes: >>>>>> 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 general agent expiration is only done when directed. However, gnus-request-expire-articles was modified to expire articles in the agent as they are expired in the group. So, it looks like your memory was correct. > >> [...] >> 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. Actually, I was thinking that the backend may have generated 414 from 12414 as part of moving an article. Now, I don't think that that happens at all. > >> 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. Sorry, but the dianostics didn't execute. I'm assuming that gnus didn't load gnus-agent until after you had loaded the temp file. As a result, the unmodified agent overwrote my diagnostics. Please repeat the test except that, before loading the temp file, you do a M-x load-library gnus-agent. I'm including a patch that I developed in response to another thread. It fixes a display update problem that I found in summary (At least I hope that it does :) ). There is a small chance that your problem has to do with updating the summary buffer rather than the agent.