GNU bug report logs - #9243
24.0.50; Gnus keeps seeing 101 unread spam

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9243 <at> debbugs.gnu.org
Subject: bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
Date: Fri, 06 Jan 2012 21:45:14 -0500

>> - seen messages re-appearing as unseen (presumably because the imap
>> connection died during the "group exit").
> That should probably be unrelated to the Agent, and won't be fixed
> during this development cycle.

AFAIK my use case is not completely unusual (typically connected via
a NAT router to my university's IMAP server) and I see this problem more
or less *every day*.
So I really hope you can try to fix this soon.
FWIW I never saw this problem with the old nnimap backend, so it's
a (very serious if you ask me) regression w.r.t Emacs-23.

And I think it is related to the agent, because the connection death
would be handled differently without the agent: the connection would be
re-established and the command re-tried, whereas with the new
"connection death silently puts the agent in offline mode", the command
just gets dropped on the floor.

> To fix this properly, Gnus would have to maintain a transaction log
> (on disk) and update the IMAP server in a "transactional" manner,
> instead of (as it does now) just sending the data to the server on
> Group exit.

Emacs-23's experience seems to indicate there's a way to get much better
behavior without going to such a transaction log.

> Some IMAP servers are really, really slow at doing expunging on big
> folders.  They basically keep all the messages in one big file, and they
> have to rewrite the entire file to delete a message, if I understand
> correctly.

That's probably what's going on (each folder is stored as a large single
file).  Can the expunging be done asynchronously?

>> - not sure if it's related, but "B m" to move stuff from a group/folder
>> to another takes *ages* (as in several minutes), and I think most of
>> this time is spent in Gnus trying to update its idea of the content of
>> the destination group (after the actual move took place).
> Huh.  Hm...  Actually, can you try the `nnimap-expunge' setting for
> this, too?

I'll try it out for a while and will tell you if it gets better,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.