move article, agent does not expire ?

move article, agent does not expire ?

[Nicolas KOWALSKI]

Hello,

I am using nnimap as backend, with agent. 

When I delete an article in a group, I see the agent is expiring old
data, like:

"Expiry recovered 1 NOV entries, deleted 0 files, and freed 233.000000B."

But when I move an article from a group to another, this expiry does not
happen, and so old data is kept into the agent. If I later come back
into that "source" group, I see the old article (marked with G), and I
can not remove it anymore. So, I currently have to copy the article in
the destination group, then delete it, to keep the agent up to date.
Even using "gnus-agent-regenerate" does not always clean up the
situation.

How can I handle this correctly ? 

Thanks.

gnus-version: No Gnus v0.6
-- 
Nicolas

Re: move article, agent does not expire ?

[Greg Troxel]

  But when I move an article from a group to another, this expiry does not
  happen, and so old data is kept into the agent. If I later come back
  into that "source" group, I see the old article (marked with G), and I
  can not remove it anymore. So, I currently have to copy the article in
  the destination group, then delete it, to keep the agent up to date.
  Even using "gnus-agent-regenerate" does not always clean up the
  situation.

I am having a problem that I think is the same one.  I use imap for
mail.  I have a function to make imap sharing with tbird etc. easier:

  d runs the command gdt-gnus-move-to-trash
    which is an interactive Lisp function in `/usr/home/gdt/.dot-gdt/.emacs'.
  It is bound to d.
  (gdt-gnus-move-to-trash)

(defun gdt-gnus-move-to-trash ()
  (interactive)
  (gnus-summary-move-article nil gdt-trash-newsgroup))


and have been noticing G articles in the summary on reentry.  I fix this
by "rm -rf News/agent".  This behavior started about 2 months ago (by
very fuzzy memory).

Re: move article, agent does not expire ?

[Nicolas KOWALSKI]

Greg Troxel <gdt@work.lexort.com> writes:

>   But when I move an article from a group to another, this expiry does not
>   happen, and so old data is kept into the agent. If I later come back
>   into that "source" group, I see the old article (marked with G), and I
>   can not remove it anymore. So, I currently have to copy the article in
>   the destination group, then delete it, to keep the agent up to date.
>   Even using "gnus-agent-regenerate" does not always clean up the
>   situation.
>
> I am having a problem that I think is the same one.  I use imap for
> mail.  I have a function to make imap sharing with tbird etc. easier:

Glad to see I am not alone.

>   d runs the command gdt-gnus-move-to-trash
>     which is an interactive Lisp function in `/usr/home/gdt/.dot-gdt/.emacs'.
>   It is bound to d.
>   (gdt-gnus-move-to-trash)
>
> (defun gdt-gnus-move-to-trash ()
>   (interactive)
>   (gnus-summary-move-article nil gdt-trash-newsgroup))

I have the same kind of function, this one for spamassassin, rewritten
to handle the current problem:

(defun nk-junk-article ()
  "Submit Spam." 
  (interactive) 
  (when (y-or-n-p "Learn this message as spam ? ")
    (gnus-summary-show-raw-article) 
    (message "Learning article as spam...")
    (gnus-summary-save-in-pipe "sa-learn --spam --no-sync")
    (when (string-match "^nnimap" gnus-newsgroup-name)
      (gnus-summary-copy-article 1 "nnimap:Junk")
      (gnus-summary-delete-article 1)
      (gnus-summary-expand-window)
      )
    )
  )


> and have been noticing G articles in the summary on reentry.  I fix this
> by "rm -rf News/agent".  This behavior started about 2 months ago (by
> very fuzzy memory).

With the above function, the 'G' articles do not reappear in the
summary, but this is a ugly workaround.

-- 
Nicolas

Re: move article, agent does not expire ?

[Malcolm Purvis]

>>>>> "Nicolas" == Nicolas KOWALSKI <niko@petole.dyndns.org> writes:

Nicolas> But when I move an article from a group to another, this expiry
Nicolas> does not happen, and so old data is kept into the agent.

I see a similar problem using imap where the agent doesn't notice that
articles have been moved by another MUA (in my case Gnus running on
another machine, and no, both Gnus are not running at the same time).

Removing ~/News/agent fixes the problem, but is there some way to get
the agent to check automatically, when plugged, that the articles in its
cache still exist?

Malcolm

-- 
		     Malcolm Purvis <malcolmp@xemacs.org>

Re: move article, agent does not expire ?

[Elias Oltmanns]

Malcolm Purvis <malcolmp@xemacs.org> wrote:
[...]
> I see a similar problem using imap where the agent doesn't notice that
> articles have been moved by another MUA (in my case Gnus running on
> another machine, and no, both Gnus are not running at the same time).

You can fix that particular issue by setting gnus-agent-cache to nil
locally for that server.

Hope that helps,

Elias

Re: move article, agent does not expire ?

[Greg Troxel]

Elias Oltmanns <eo@nebensachen.de> writes:

> Malcolm Purvis <malcolmp@xemacs.org> wrote:
> [...]
>> I see a similar problem using imap where the agent doesn't notice that
>> articles have been moved by another MUA (in my case Gnus running on
>> another machine, and no, both Gnus are not running at the same time).
>
> You can fix that particular issue by setting gnus-agent-cache to nil
> locally for that server.

Probably then the agent cache should be disabled by default for IMAP.
Other clients doing things to the IMAP server, even while gnus has a
connection open, is quite normal.

Re: move article, agent does not expire ?

[Malcolm Purvis]

>>>>> "Elias" == Elias Oltmanns <eo@nebensachen.de> writes:

Elias> Malcolm Purvis <malcolmp@xemacs.org> wrote: [...]
>> I see a similar problem using imap where the agent doesn't notice
>> that articles have been moved by another MUA (in my case Gnus running
>> on another machine, and no, both Gnus are not running at the same
>> time).

Elias> You can fix that particular issue by setting gnus-agent-cache to
Elias> nil locally for that server.

I've run this for a few days and it has certainly helped.

Thanks!

Malcolm

-- 
		     Malcolm Purvis <malcolmp@xemacs.org>