Re: mutt/2152: new read mail in IMAP folder not seen
The following reply was made to PR mutt/2152; it has been noted by GNATS.
From: Brendan Cully <brendan@xxxxxxxxxx>
To: Phil Pennock <muttbug@xxxxxxxxxxxxxxxxx>
Cc: bug-any@xxxxxxxxxxxxx
Subject: Re: mutt/2152: new read mail in IMAP folder not seen
Date: Thu, 15 Dec 2005 10:52:43 -0800
On Thursday, 15 December 2005 at 19:38, Phil Pennock wrote:
> On 2005-12-15 at 18:27 +0100, Brendan Cully wrote:
> > Synopsis: new read mail in IMAP folder not seen
> >
> > **** Comment added by brendan on Thu, 15 Dec 2005 18:27:32 +0100 ****
> > I can't reproduce this with current CVS. The mail arrives in the first
> > mutt (not marked new) as soon as I leave the message view (with debian
> > cyrus 2.1.18). A longer trace would be needed...
>
> Updated to CVS.
>
> The ChangeLog is informative (latest "2005-12-14 17:29:57").
>
> Trying the new code and looking at debug traces ... the new approach is
> to poll every mailbox, always? That will cause hideous performance
not new. That code hasn't changed in years. It's not related to the
bug you described either - polling other mailboxes is done completely
differently from polling the selected one.
> problems for anyone using UW imapd as a front-end onto a regular mbox
> folder, since that will involve recalculations for every folder (hence
> the strenuous Thou Shalt Nots in RFC3501). I use Cyrus (mostly), so am
> happy enough with the behaviour, but a friend will murder me if I try to
> run this against his UW server.
It polls every mailbox you've told it to poll using a mailboxes
command or imap_check_subscribed. This is usually much less than the
total set of mailboxes you can access. Right now it's only asking for
RECENT, which only a silly mail server should have a hard time
calculating (MESSAGES is a different story), and there's not much you
can do to make it better. You either run STATUS on other mailboxes, or
hold them open. UW doesn't like that either, since it locks the
mailbox. UW is not a good IMAP server, or at least mbox is a very bad
back end.
But make sure you drop mail_check down to something sensible
(ie 60+). 5 is insane for IMAP. And for everything else, really.
I'm currently playing with a rewrite that uses UIDNEXT instead of
RECENT to work around the ephemeral nature of the RECENT flag, but it
will actually be marginally more expensive for the server.
> Is the imap-fetch-mail command expected to disappear? Because it in
> itself is not causing the mail fetch (as far as I can figure out); it's
> being independently determined elsewhere by the STATUS polls.
it's a silly function, but it'll probably hang around a bit
longer. New mail in the current mailbox is checked with NOOP or IDLE,
which should be very cheap.