[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
From: |
Stefan Monnier |
Subject: |
bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam |
Date: |
Fri, 06 Jan 2012 21:45:14 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
>> - 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