23444 - [DOGFOOD] Move message to IMAP folder loses message

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[Richard Zach]

Moving a message from a local folder to an IMAP folder fails, and the message is
lost.

To reproduce:
1. Open local mail folder (or POP folder)
2. Select a message
3. Message | Move message | IMAP folder

Result: The message is removed from the local folder, selection moves on to the
next message, an alert window is displayed: "The current command did not succeed
. The mail server responded:Empty message to APPEND".  The message is not in the
target folder.

Subsequent attempts to move a message from a local folder to an IMAP folder do
not produce an error message; the message is not removed from the source folder;
only the selection moved to the next message.

Linux build 2000.01.08.08

Comment 1

[Phil Peterson]

Reassign to jefft, cc bienvenu

Comment 2

[rickg]

Data loss is bad, marking PDT+.

Comment 3

[jefft]

Zach, could you try the latest build. I couldn't reproduce the problem with my
debug build (01-11-2000). Everything works fine for me.

Comment 4

[Richard Zach]

Linux build 2000.01.11.08

Same thing still happens.  On another IMAP server, I get the following alert
when I move a message to it:

"The current command did not succeed.  The mail server responded: Message has no
header/body separator"

Comment 5

[Karen Huang]

I couldn't reproduce this problem either with the latest Linux 2000-01-11-09-M13
commercial build.....It works for me, too.

Comment 6

[jefft]

zach, could you attach the message that you were trying to copy to this bug?
Also, make sure that the destination Imap folder do exist and have no problem
viewing messages within that folder. Thanks,

Comment 7

[David :Bienvenu]

perhaps it's specific to the server, not the message.

Comment 8

[Richard Zach]

It happens with any message.  And I think my servers are fine: it works under
NS4.7.  And I can view the target folders etc.

There are really two problems here:
1. It looks to me like when you move a message from X to Y, you first remove it
from X and then store it on Y.  It should be the other way round.

Here's a way to test this with any server, if you have shell access to it:
a. Create new IMAP folder
b. Login to sevrer, delete the corresponing mbox
c. In Mozilla, move a message to the new but nonexistent folder

You'll see the message be removed from the source folder, then an error message:
SELECT failed: No such mailbox.

2. For some reason, my IMAP servers don't like the way Mozilla says STORE to
them (I assume that's what you use to move a message to an IMAP folder).  Any
way I can get a trace of the conversation b/w Mozilla and the server to show to you?

Comment 9

[David :Bienvenu]

yes, shutdown mozilla and set the following environment variables

setenv NSPR_LOG_MODULES IMAP:5
setenv NSPR_LOG_FILE /tmp/mapio.txt

and run mozilla. /tmp/mapio.txt (/tmp must exist) will contain the log. Remove
the password info and attach it to this bug.

Comment 10

[jefft]

Yes, you can turn on the client imap log by setting the following environment
varibles:

setenv NSPR_LOG_FILE ~/tmp/imapio.txt
setenv NSPR_LOG_MODULES IMAP:5

Thanks much for additional info. I think I can reproduce the problem.

Comment 11

[David :Bienvenu]

Since I reworking all the offline <-> online imap stuff, do you want to just
reassign this to me, Jeff?

Comment 12

[Richard Zach]

Attachment: Conversations with my IMAP servers. Look for !!! - move message starts there

Comment 13

[jefft]

zach, a complete log would be more useful. :-)

Comment 14

[jefft]

Off to bienvenu ...

Comment 15

[Richard Zach]

Attachment: complete session transcript

Comment 16

[Richard Zach]

Attachment: the message I tried to move

Comment 17

[Richard Zach]

Attachment: the message, this time without the rest of the mailbox

Comment 18

[David :Bienvenu]

Moving to m14 - I haven't got a chance to deal with this code yet; I was working
on moving messages the other way. Since I can't reproduce this, I don't think it
should be a PDT+ bug myself.

Comment 19

[David :Bienvenu]

OK, I fixed this by adding a check in nsImapProtocol.cpp to see if the
LastCommandWasSuccessful before invoking the next copy operation, which in this
case turns out to be the delete. I was not able to recreate Zach's 0 length
append problem - I'm not sure if his msf file was messed up, or there was some
error copying his message to a temp file before uploading. Or, his local folder
might have been messed up - that From - From line is very suspicious.

Comment 20

[Karen Huang]

David, if after I removed the ".mozilla" directory....it's no problem for the 
*FIRST* time if I move the messages from Local folders to IMAP server's folders.
But if I tried from the second time, seamonkey will hang....It seems that it 
does not move message successfully *everytime*.....seamonkey hang three times if 
I tried 5 times...

Comment 21

[David :Bienvenu]

Weird, I did it five times in a row without a problem. Are you moving a single 
message from a local folder to an imap folder, or multiple messages?

Comment 22

[Karen Huang]

Yes. I moved single message.

Comment 23

[Karen Huang]

I tried on today's Linux Mozilla build: 2000-01-28-09-M14 Mozilla build.
It's better than yesterday's Linux commercial build, there is no hang for
today's Linux build and local messages have been moved to IMAP server folders
successfully....
Since Jan need to know the status for this bug...Cc: Jan.
Jan, do you want me to close this bug for today's mozilla build or verified on
next or tomorrow commercial build again?

Comment 24

[Karen Huang]

Marking as verified based on it's working fine for today's Linux Mozilla build.

Comment 25

[Richard Zach]

On Linux build 2000.01.31.14, I still see the exact same behavior as originally
described.  Move single message from local folder to UW IMAP folder gives "Empty
message to APPEND" error; on Cyrus gives "Message has no header/body
separator".  The message is removed from the local folder's msf file and
disappears from the thread pane, although it's still in the actual mailbox file.

Comment 26

[David :Bienvenu]

I was never able to recreate your zero length problem; I was only able to try to 
move a message to a folder that doesn't exist, and I fixed that. Perhaps the 
append case causes a different error - I can't know without knowing how to 
recreate your problem. Have you tried removing your .msf file?

Comment 27

[Karen Huang]

Used today's Linux 02-01-08-M14 mozilla build:
I was not able to reproduce this problem on both "Netscape Messaging IMAP 
server" & "UW IMAP server"....
zach, from the log -- you are using UW IMAP, can you try to reproduce this 
problem again on today's build?

Comment 28

[Richard Zach]

Happens still on 2000.02.01.10.  I deleted the msf files as David suggested.  I
get the same result, though different error messages with UW and Cyrus.  I'll
attach the mailbox before and after the unsuccessful move.  I tried to move the
first message; its X-Mozilla-Status header changed to 0009 after the move and no
longer appears in the thread pane.

Regardless of what causes the zero length append, the fix in nsImapProtocol of
1/26 should maybe check for other error codes than folder not found.  Have you
tested what happens if the network connection goes down in the middle of a move?

Comment 29

[Richard Zach]

Attachment: mailbox before move

Comment 30

[Richard Zach]

Attachment: Mailbox after attempted to move first message

Comment 31

[David :Bienvenu]

Oh, I'm not checking for folder not found; I'm checking for "last command 
successful". It could be somehow that a failed append is not setting that status 
in all cases; I don't know, I didn't write that code.

Comment 32

[Richard Zach]

Ok, then I'm marking this fixed again.  Do you want to file a bug against mscott
regarding the IMAP error not being caught?

Comment 33

[Karen Huang]

Yes. zach, you may go ahead to log a bug for the "IMAP error not being caught" 
issue. And please Cc:me for that bug. Thanks.

Marking as verified for this bug.

Comment 34

[David :Bienvenu]

No, please don't open a new bug. Richard and I tracked it down to two separate 
problems, both of which I have fixes for. The initial problem is that we're 
creating the temp file in the current directory, which is a no-no, because on 
unix, that's very likely a readonly directory.  We were also deleting the source 
message after spooling it to a temp file, and before we even started to upload 
it to the imap server. I have a fix for that as well.

Comment 35

[Karen Huang]

OK. zach, then please don't open that bug. Thanks.