From: Kevin Greiner <kgreiner@xpediantsolutions.com>
Subject: Re: gnus-agent-expire detected a missing NOV entry
Date: Tue, 21 Oct 2003 21:29:02 -0500 [thread overview]
Message-ID: <uhe22ovip.fsf@xpediantsolutions.com> (raw)
In-Reply-To: <86u165obyc.fsf@doze.rijnh.nl>
Jochen Küpper <usenet@jochen-kuepper.de> writes:
> On Sun, 19 Oct 2003 01:59:44 +0200 Simon Josefsson wrote:
>
> Simon> If it isn't a bug, at least those messages should use a higher
> Simon> gnus-verbose setting so they don't clutter the screen all the
> Simon> time.
>
> It's actually not only cluttering the screen, but really a performance
> problem. After a while I get easily several tens (even hundreds) of
> these messages per B m'ed message; if I then move 5 or ten messages
> somewhere else you recognize that it takes longer than without these
> warnings. (This might be Cygwin specific?)
>
> Simon> No idea on fixing it though.
>
> Well, somehow the agent seems to miss the removal of messages; maybe
> there is already functionality to do that for a single message?
gnus-agent-expire has a force option that is used in one place to
remove single articles. I need to see how nnimap is handling this
operation to understand why the agent is getting corrupted.
> Maybe calling gnus-agent-regenerate-group after removing an article
> From agentized groups is not too much of a hog?
That's probable, group regeneration was written to recover from errors
and not as a tool to cheaply sync the agent with a back end.
In this particular case, some function apparently deleted the agent's
local article file without also updating agent's internal data
structures. That's why the gnus-verbose setting on these messages is
so low. The agent is reporting data integrity errors that the agent
is now having to correct. If you didn't see these messages, and
complain about them, I'd never get this cleaned up.
The 'B m' command is bound to gnus-summary-move-article but it doesn't
invoke the agent directly. Could either of you set debug-on-entry on
gnus-agent-expire-group-1 then post the stack trace. That will help
me isolate where the error is likely to have occurred. In the
meantime, I'll see if I can set up an imap environment where I can
duplicate this error.
Kevin
parent reply other threads:[~2003-10-22 2:29 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <86u165obyc.fsf@doze.rijnh.nl>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uhe22ovip.fsf@xpediantsolutions.com \
--to=kgreiner@xpediantsolutions.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).