On Saturday, 17 December 2005 at 19:09, Phil Pennock wrote: > On 2005-12-16 at 10:29 -0800, Brendan Cully wrote: > > I've just changed the way mutt detects new mail for IMAP > > folders. > [ UID* bits ] > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I/usr/include// > -I/usr/include/heimdal -I../intl -Wall -pedantic -g -O2 -c imap.c > imap.c: In function `imap_open_mailbox': > imap.c:683: warning: long unsigned int format, unsigned int arg (arg 3) > > The code is: > sscanf (pc, "%lu", &status->uidnext); > which is part of the new code (rev 3.54). > > IMAP_STATUS.uidnext in imap_private.h is unsigned int; since the UID is > defined as being 32-bit, for portability perhaps it should be declared > as being either unsigned long or uint32_t (although mutt only appears to > use that in the MD5/SHA1 code, it is already relied upon)? ok, I'll try to be more careful of this. > Trying to check the 'new' mail issue, in a second mail-client I can't > even see the new mail with sync-mailbox or imap-fetch-mail or waiting a > while and it took well over a minute for the message to become visible. > $timeout=15 $imap_idle=on $mail_check=60 ; I think that it took > $mail_check for this to become visible, despite the imap-fetch-mail > invocations. A third instance of mutt was able to see the new mail, > whilst I was trying to make the mail visible in the second instance. > The mail was still New whilst this was going on. I've been playing with idling in a very tight loop (imap_keepalive < 30) on a cyrus 2.2 server and it seems that if the loop is too tight I never receive notifications either. I suspect there's some kind of locking bug in Cyrus. Note that IDLE doesn't mean instant notification, it just means notification whenever the server gets around to noticing. I think the default poll interval for cyrus is 60 seconds. > On a second test, I opened one instance on the folder (INBOX, as it > happens), opened a second instance, sent the mail, confirmed not > visible, quit, started a new second instance of mutt, marked the mail > read, quit. Went back to the first instance, which would not see the > extra mail, even after three minutes had passed. > > Ah, just before sending this, I went back and tried a sync once more, > and at 19:08 local time, the mail sent at 19:04 became visible; I'd > previously most recently tried at 19:07. As far as I can tell so far, the problem is that mutt is simply not getting notified about new mail, rather than that it is getting notified and forgetting about it. If that's so, my current advice would be to keep any eye on your logs and try to get mutt to poll _less_ frequently. Keep imap_keepalive at its default value, for instance.
Attachment:
pgpvKtn1ukqbu.pgp
Description: PGP signature