I'm having a bit of misbehavior wherein Dovecot seems to refuse to
cooperate with my Mulberry MUA. By and large, everything works great.
I can move mail back and forth happily. I can compose a note and copy
the outgoing mail to my Dovecot "Sent" folder using my default
Mulberry
settings. But if I reply or forward a mail, I get a Mulberry error popup
saying that it "couldn't decode the response from the server" and
that
the operation was unsuccessful.
This was somewhat mystifying (especially since this does work for a newly
composed message as opposed to a reply/forward), so I turned on Mulberry
logging.
This is what I see (with unrelated operations clipped from the log).
First, the first case where I create a new message, send it, and save
a copy in my Sent folder:
--> #6.3408 Mon Sep 5 23:24:27 2005
A00085 APPEND Sent (\Seen) {418+}
* 5544 EXISTS
* 1 RECENT
A00085 OK Append completed.
All's well there. Mulberry does a FETCH to grab the new message (reply)
from my Sent folder and then does a SORT so that it can order it properly
in the display. This too succeeds but is probably irrelevant to us.
After a couple NOOP commands come and go in the background, I try to
reply to a message in one of my mailboxes. In this case it happens to
be the one in my Sent folder.
So Mulberry issues a FETCH (you can see the original mail there in the
FETCH response from Dovecot). It then does a STORE of the original mail,
apparently to update the \Answered flag.
It then tries to APPEND the reply to the Sent folder, but this time,
the server comes back with a NO. See below
--> #6.3408 Mon Sep 5 23:24:43 2005
A00089 FETCH 5544 (BODY[1])
* 5544 FETCH (BODY[1] {63}
)
A00089 OK Fetch completed.
--> #6.3408 Mon Sep 5 23:25:13 2005
A00090 FETCH 5544 (RFC822.HEADER)
* 5544 FETCH (RFC822.HEADER {355}
Date: Mon, 05 Sep 2005 23:24:27 -0500
From: Jon Roma <roma at uiuc.edu>
To: Jon R Roma <roma at uiuc.edu>
Subject: Test 1
Message-ID: <DDDD999F0F4E38F8C1510CC8 at jrr2.isdn.uiuc.edu>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
)
A00090 OK Fetch completed.
--> #6.3408 Mon Sep 5 23:25:13 2005
A00091 STORE 5544 +FLAGS (\Answered)
* 5544 FETCH (FLAGS (\Answered \Seen \Recent))
A00091 OK Store completed.
--> #6.3408 Mon Sep 5 23:25:13 2005
A00092 APPEND Sent (\Seen) {610+}
A00092 NO
I am having similar problem saving a draft to my Drafts folder and
suspect the same thing is behind both of these. I didn't create a
Mulberry trace log for this but can do so if need be.
I am running 1.0-test80 with Timo's patch to fix the "time off by
200 minutes" error with mbox. All my folders are maildir at this
point -- I've converted them out of my UW mbx format store. My
client is Mulberry 3.1.6 for Windows and the OS is AIX 5.1.
This weird behavior is a mystery to me!
On Mon, 2005-09-05 at 23:57 -0500, Jon Roma wrote:> --> #6.3408 Mon Sep 5 23:25:13 2005 > A00092 APPEND Sent (\Seen) {610+} > A00092 NOThat happens if some function returned -1 but didn't set any error. Shouldn't happen..> I am running 1.0-test80 with Timo's patch to fix the "time off by > 200 minutes" error with mbox. All my folders are maildir at this > point -- I've converted them out of my UW mbx format store. My > client is Mulberry 3.1.6 for Windows and the OS is AIX 5.1.So, they are maildirs? Do these changes help: Index: src/imap/cmd-append.c ==================================================================RCS file: /var/lib/cvs/dovecot/src/imap/cmd-append.c,v retrieving revision 1.64 retrieving revision 1.65 diff -u -r1.64 -r1.65 --- src/imap/cmd-append.c 28 Jun 2005 11:15:57 -0000 1.64 +++ src/imap/cmd-append.c 18 Sep 2005 16:58:01 -0000 1.65 @@ -292,8 +292,7 @@ int failed; if (ctx->save_ctx != NULL) { - if (mailbox_save_continue(ctx->save_ctx) < 0 || - client->input->closed) { + if (mailbox_save_continue(ctx->save_ctx) < 0) { /* we still have to finish reading the message from client */ mailbox_save_cancel(ctx->save_ctx); Index: src/lib-storage/index/maildir/maildir-save.c ==================================================================RCS file: /var/lib/cvs/dovecot/src/lib-storage/index/maildir/maildir-save.c,v retrieving revision 1.57 retrieving revision 1.58 diff -u -r1.57 -r1.58 --- src/lib-storage/index/maildir/maildir-save.c 14 Aug 2005 19:02:54 -0000 1.57 +++ src/lib-storage/index/maildir/maildir-save.c 18 Sep 2005 16:58:31 -0000 1.58 @@ -217,6 +217,10 @@ return -1; if (o_stream_send_istream(ctx->output, ctx->input) < 0) { + mail_storage_set_critical(STORAGE(ctx->mbox->storage), + "o_stream_send_istream(%s) failed: %m", + t_strconcat(ctx->tmpdir, "/", + ctx->files->basename, NULL)); ctx->failed = TRUE; return -1; } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050918/b2ac52e1/attachment.bin>
Well, ironically after my tests succeeded, my reply to the Dovecot list just now failed to append to the Dovecot maildir folder. So I guess it works sometimes and not other times. :( The error message is the same "failed: Invalid argument". Jon Roma <roma at uiuc.edu> wrote:> > > Timo Sirainen <tss at iki.fi> wrote: > >> On Mon, 2005-09-05 at 23:57 -0500, Jon Roma wrote: >>> --> #6.3408 Mon Sep 5 23:25:13 2005 >>> A00092 APPEND Sent (\Seen) {610+} >>> A00092 NO >> >> That happens if some function returned -1 but didn't set any error. >> Shouldn't happen.. >> >>> I am running 1.0-test80 with Timo's patch to fix the "time off by >>> 200 minutes" error with mbox. All my folders are maildir at this >>> point -- I've converted them out of my UW mbx format store. My >>> client is Mulberry 3.1.6 for Windows and the OS is AIX 5.1. >> >> So, they are maildirs? Do these changes help: >> >> Index: src/imap/cmd-append.c >> ==================================================================>> RCS file: /var/lib/cvs/dovecot/src/imap/cmd-append.c,v >> retrieving revision 1.64 >> retrieving revision 1.65 >> diff -u -r1.64 -r1.65 >> --- src/imap/cmd-append.c 28 Jun 2005 11:15:57 -0000 1.64 >> +++ src/imap/cmd-append.c 18 Sep 2005 16:58:01 -0000 1.65 >> @@ -292,8 +292,7 @@ >> int failed; >> >> if (ctx->save_ctx != NULL) { >> - if (mailbox_save_continue(ctx->save_ctx) < 0 || >> - client->input->closed) { >> + if (mailbox_save_continue(ctx->save_ctx) < 0) { >> /* we still have to finish reading the message >> from client */ >> mailbox_save_cancel(ctx->save_ctx); >> Index: src/lib-storage/index/maildir/maildir-save.c >> ==================================================================>> RCS file: >> /var/lib/cvs/dovecot/src/lib-storage/index/maildir/maildir-save.c,v >> retrieving revision 1.57 >> retrieving revision 1.58 >> diff -u -r1.57 -r1.58 >> --- src/lib-storage/index/maildir/maildir-save.c 14 Aug 2005 19:02:54 >> -0000 1.57 +++ src/lib-storage/index/maildir/maildir-save.c 18 Sep 2005 >> 16:58:31 -0000 1.58 @@ -217,6 +217,10 @@ >> return -1; >> >> if (o_stream_send_istream(ctx->output, ctx->input) < 0) { >> + mail_storage_set_critical(STORAGE(ctx->mbox->storage), >> + "o_stream_send_istream(%s) failed: %m", >> + t_strconcat(ctx->tmpdir, "/", >> + ctx->files->basename, NULL)); >> ctx->failed = TRUE; >> return -1; >> } >> > > Timo: > > Yes, my mailboxes are maildirs. > > Your patch seems to have fixed the problem -- I can now append outgoing > mail to a Dovecot maildir 'Sent' mailbox as it gets sent. And I can now > also save a draft in my Dovecot maildir 'Drafts' mailbox when desired. > > What this means is that I no longer need UW (Yay!) -- I was saving my > outgoing mail and drafts in a skeletal UW tree pending resolution of > this problem. > > There is still an anomaly when using the Mulberry client to move mail > from the UW tree to Dovecot (which I now want to do in preparation for > getting rid of UW imapd. > > Using Mulberry to move mail from UW to Dovecot only works with some > messages and not others. Maybe this is not important -- I can slurp > my last two UW mboxes into a Dovecot namespace and then move them as > desired into the default namespace. > > But perhaps this behavior is something you are interested in -- here's > the transcript on the client side. > > First a copy/move that succeeded. I am in the source folder (under UW) > and have chosen a message that I want to move to the Dovecot 'Sent' > folder is the destination. > > --> #25.2768 Sun Sep 18 13:10:26 2005 > A00145 FETCH 170 (BODY[1]) > * 170 FETCH (BODY[1] {280} > ) > A00145 OK FETCH completed > > --> #1.2768 Sun Sep 18 13:10:34 2005 > A00010 APPEND Sent (\Seen) "15-Sep-2005 18:00:43 -0500" {813+} > --> #25.2768 Sun Sep 18 13:10:34 2005 > A00146 FETCH 170 (BODY.PEEK[]) > * 170 FETCH (BODY[] {813} > ) > A00146 OK FETCH completed > > A00010 OK Append completed. > > --> #1.2768 Sun Sep 18 13:10:35 2005 > A00011 STATUS Sent (MESSAGES RECENT UNSEEN UIDVALIDITY UIDNEXT) > * STATUS "Sent" (MESSAGES 5547 RECENT 1 UIDNEXT 5552 UIDVALIDITY > 1125869336 UNSEEN 0) > A00011 OK Status completed. > > --> #25.2768 Sun Sep 18 13:10:35 2005 > A00147 STORE 170 +FLAGS (\Deleted) > * 170 FETCH (FLAGS (\Seen \Deleted)) > A00147 OK STORE completed > > This move succeeded. > > Now I choose a different message in Mulberry and try to do the same > move operation. This one fails. > > --> #25.2768 Sun Sep 18 13:10:35 2005 > A00148 FETCH 171 (BODY[1]) > * 171 FETCH (BODY[1] {268} > ) > A00148 OK FETCH completed > > --> #1.2768 Sun Sep 18 13:10:44 2005 > A00012 APPEND Sent (\Seen) "15-Sep-2005 19:52:14 -0500" {832+} > --> #25.2768 Sun Sep 18 13:10:44 2005 > A00149 FETCH 171 (BODY.PEEK[]) > * 171 FETCH (BODY[] {832} > ) > A00149 OK FETCH completed > > A00012 NO Internal error occurred. Refer to server log for more > information. [2005-09-18 13:10:44] > > The corresponding syslog message is > > Sep 18 13:10:44 zippy dovecot: IMAP(roma): o_stream_send_istrea > (/var/imap/dovecot/roma/.Sent/tmp/1127067044.P44216Q3.zippy.cso.uiuc.edu) > failed: Invalid argument > > Maybe this isn't important, but I send it in case you think it's something > you want to look at. > > I'll leave the relevant mailbox around so I can try this again if > necessary. > > Thanks for the patch!
Sorry about that last -- Windows seems to have mangled the attachment.
Retrying here.
-------------- next part --------------
Index: src/lib/ostream-file.c
==================================================================---
src/lib/ostream-file.c (revision 2865)
+++ src/lib/ostream-file.c (working copy)
@@ -17,8 +17,8 @@
# include <sys/uio.h>
#endif
-#ifndef UIO_MAXIOV
-# define UIO_MAXIOV 16
+#ifndef IOV_MAX
+# define IOV_MAX 16
#endif
/* try to keep the buffer size within 4k..128k. ReiserFS may actually return
@@ -137,22 +137,22 @@
ret = write(fstream->fd, iov->iov_base, iov->iov_len);
else {
sent = 0;
- while (iov_size > UIO_MAXIOV) {
+ while (iov_size > IOV_MAX) {
size = 0;
- for (i = 0; i < UIO_MAXIOV; i++)
+ for (i = 0; i < IOV_MAX; i++)
size += iov[i].iov_len;
ret = writev(fstream->fd, (const struct iovec *)iov,
- UIO_MAXIOV);
+ IOV_MAX);
if (ret != (ssize_t)size)
break;
sent += ret;
- iov += UIO_MAXIOV;
- iov_size -= UIO_MAXIOV;
+ iov += IOV_MAX;
+ iov_size -= IOV_MAX;
}
- if (iov_size <= UIO_MAXIOV) {
+ if (iov_size <= IOV_MAX) {
ret = writev(fstream->fd, (const struct iovec *)iov,
iov_size);
}