On Tuesday, 20 December 2005 at 06:00, Vincent Lefevre wrote:
> On 2005-12-20 03:20:29 +0100, Vincent Lefevre wrote:
> > On 2005-12-19 10:05:34 -0800, Brendan Cully wrote:
> > > Actually I think the fix may be trivial. Try pulling the latest CVS
> > > (there should be a note in the Changelog about "another possible data
> > > race" in the IDLE code) and see how it goes.
> >
> > I've restarted the new version...
>
> and the problem is not fixed. Mutt tells me that there are new messages
> but doesn't show them (the number of messages remain the same, and after
> deleting a message, it decreased by 1).
well, it's progress. At least the IDLE command no longer thinks it's
failed. I found another possible bug, and I think This Time It's
Really It.
> > DONE
> a0008 IDLE
> < * 224 EXISTS
> Handling EXISTS
> cmd_handle_untagged: New mail in INBOX - 224 messages total.
> < * 1 RECENT
> < * OK Timeout in 30 minutes
> < a0007 OK IDLE completed
> imap_cmd_finish: Fetching new mail
> message.c:92: mutt_mktemp returns "/var/tmp/mutt-dixsept-325-3688-1".
> > DONE
> a0009 FETCH 224:224 (UID FLAGS INTERNALDATE RFC822.SIZE
> BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES
> CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST
> X-LABEL)])
> < + Waiting for DONE
This +, which belongs to the IDLE command, doesn't arrive until mutt
has already sent the FETCH command. In the FETCH handler mutt isn't
expecting anything but * responses and bails out. I should probably
add some logging code in that path.
> < a0008 OK IDLE completed
> < * 224 FETCH (UID 205665 FLAGS (\Recent) INTERNALDATE "20-Dec-2005 05:47:21
> +0100" RFC822.SIZE 1311 BODY[HEADER.FIELDS ("DATE" "FROM" "SUBJECT" "TO" "CC"
> "MESSAGE-ID" "REFERENCES" "CONTENT-TYPE" "CONTENT-DESCRIPTION" "IN-REPLY-TO"
> "REPLY-TO" "LINES" "LIST-POST" "X-LABEL")] {251}
Try the attached patch, if you still have the patience.
Merci beacoup pour l'assistance :)
diff -r 0dd50dee0e8a imap/command.c
--- a/imap/command.c Tue Dec 20 04:55:34 2005
+++ b/imap/command.c Mon Dec 19 21:41:54 2005
@@ -170,8 +170,11 @@
cmd_handle_untagged (idata))
return IMAP_CMD_BAD;
- /* server demands a continuation response from us */
- if (idata->buf[0] == '+')
+ /* server demands a continuation response from us. If the previous command
+ * has not yet completed, assume we've already sent the response. Can
+ * happen if we IDLE and then fetch new mail before the + arrives. */
+ if (idata->buf[0] == '+'
+ && (idata->lastcmd + 1) % IMAP_PIPELINE_DEPTH == idata->nextcmd)
return IMAP_CMD_RESPOND;
/* tagged completion code. TODO: I believe commands will always be completed
Attachment:
pgpTUXDadMPmE.pgp
Description: PGP signature