|
From: Sunil S. <sh...@bo...> - 2006-02-28 09:21:18
|
Quoting from Matthias Andree's mail on Mon, Feb 27, 2006:
> Brendan Lynch <bre...@ai...> writes:
> Can I see a "fetchmail -Nvvv --nosyslog" trace of a failing IMAP session
> with NOOP emulation?
>
> > A second, more minor problem is that getting a "* RECENT" notification
> > does not break a caller out of the imap_idle's imap_ok() call. This
> > causes an extra 28second wait after being notified about a message
> > before it is actually received.
> >
> > Diffs for the complete set of changes against 6.3.2 are attached to this
> > email.
> >
> > I have seen this in fetchmail 6.2.5 and 6.3.2 on linux platforms, but
> > this problem should be generic to all platforms.
> > diff -Naur fetchmail-6.3.2/imap.c fetchmail-6.3.2a/imap.c
> > --- fetchmail-6.3.2/imap.c 2006-01-20 10:38:45.000000000 +0000
> > +++ fetchmail-6.3.2a/imap.c 2006-02-23 23:54:52.000000000 +0000
> > @@ -116,6 +116,17 @@
> > {
> > recentcount_ok = 1;
> > recentcount = atoi(buf+2);
> > + /*
> > + * Kluge to handle IDLE simulation. If we are in STAGE_IDLE and
> > + * we are simulating (has_idle unset) we need to alert calling
> > + * imap_idle() to the fact that we have received a new "recent"
> > + * alert in order to break the imap_idle() out of its wait.
> > + */
> > + if (!has_idle && stage == STAGE_IDLE)
> > + {
> > + mytimeout = saved_timeout;
> > + stage = STAGE_FETCH;
> > + }
> > }
> > else if (strstr(buf, " EXPUNGE"))
> > {
>
> This looks acceptable.
>
> How can a server mark a new message "RECENT" without also sending an
> "EXISTS"? I'm inclined to consider such behavior broken. I'm willing to
> apply this nonetheless as I don't think it would hurt anyone.
I think, it would still be advisable to first get the output of
"fetchmail -Nvv --nosyslog" before accepting the patch. It is possible
that the problem lies elsewhere.
--
Sunil Shetye.
|