From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/61565 Path: news.gmane.org!not-for-mail From: "Kevin Greiner" Newsgroups: gmane.emacs.gnus.general Subject: Re: Agent expiration Date: Thu, 15 Dec 2005 16:38:56 -0600 Message-ID: <200512151638.AA38928532@mail.ev1.net> Reply-To: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134686758 31412 80.91.229.2 (15 Dec 2005 22:45:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2005 22:45:58 +0000 (UTC) Original-X-From: ding-owner+m10097@lists.math.uh.edu Thu Dec 15 23:45:51 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1En1r8-0005Rf-TI for ding-account@gmane.org; Thu, 15 Dec 2005 23:45:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1En1qy-00019K-00; Thu, 15 Dec 2005 16:45:36 -0600 Original-Received: from nas01.math.uh.edu ([129.7.128.39]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1En1nc-00019F-00 for ding@lists.math.uh.edu; Thu, 15 Dec 2005 16:42:08 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas01.math.uh.edu with esmtp (Exim 4.52) id 1En1na-0002iB-HB for ding@lists.math.uh.edu; Thu, 15 Dec 2005 16:42:08 -0600 Original-Received: from webmail5.ev1.net ([207.218.192.44] helo=mail.ev1.net) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1En1nZ-00028b-00 for ; Thu, 15 Dec 2005 23:42:05 +0100 X-Sender: Original-To: gnus-devel , Gregory Novak X-Mailer: X-Spam-Score: -2.6 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:61565 Archived-At: From: Gregory Novak >>> [I]s there a command to remove messages from the agent that have >>> disappeared from the imap server? gnus-agent-expire doesn't (seem) >>> to do what I want, given that it will get rid of all messages older >>> than some age. >> >> gnus-agent-regenerate-group may help (but may be harmful too, I don't >> really know). > >I've seen similarly cryptic and vaguely frightening comments about >gnus-agent-regenerate-group on archives of this list I've been reading >over the past week or so. Could someone elaborate about what's going >on with this command? I'm not at all certain how the "vaguely frightening" comments came to be except that, like all rumors on the net, they do seem to have a life of their own. They may have actually resulted from my discouraging people from running gnus-agent-regenerate-group every time they entered, or exited, a group. It's a CPU/time expensive function to call and, if things are working as intended, completely unnecessary. The original need for regenerate group came about to help users whose connections were dropped while downloading content. The architecture of the agent is such that article content is first fetched and parsed into individual files. Later, the group status is updated to indicate that those articles have been downloaded. As a result, if you lost your connection in the middle of a download, you would have downloaded articles on your hard drive that where not known to gnus. If you tried downloading again, you would end up downloading the same articles that are already on your hard drive. If you instead used gnus-agent-regenerate-group, gnus would be updated to know about all of the downloaded articles. After building that, I realized that gnus-agent-regenerate-group offered all sorts of interesting possibilities. As a result, I added the option to mark downloaded articles as unread. With the current capabilities you can, for example, move downloaded articles between servers and/or groups. As for sync'ing the agent with your imap server, that is a bit of a problem. The issue is that the agent is middleware that has no knowledge of the backend server. I'll use an example to explain. Let's say that you have 10 messages in your imap folder and that you've used gnus to view the list of messages. At this point, gnus knows that you have 10 unread messages. The next time you open this folder, gnus will send a command asking for the headers of 10 articles. If the agent is turned off, this request is sent to nnimap which might only return 7 headers(3 having been expired, moved, etc outside of gnus control). On the other hand, if the agent is turned on, the agent will intercept the original header request and return the 10 headers from your hard drive. The result is you see articles that no longer exist on your server. If you had deleted those articles using gnus, then gnus would know that only 7 articles existed so it would never have requested the 3 deleted articles from the agent. I haven't tried this as I don't use nnimap except for testing the agent but it is easy and safe. Try turning the agent off for your nnimap server then open the out-of-sync folder. Gnus may, as a side-effect of parsing your server's response, update its own state to remember the changes that have occurred in your imap server. If that is actually true, you will be able to turn the agent back on and not see the out-of-date articles. Kevin ________________________________________________________________ Sent via the EV1 webmail system at mail.ev1.net