[DOGFOOD] Move message to IMAP folder loses message

VERIFIED FIXED in M14

Status

P3
major
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: rzach, Assigned: Bienvenu)

Tracking

Trunk
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 2/05/00)

Attachments

(6 attachments)

(Reporter)

Description

19 years ago
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

Updated

19 years ago
QA Contact: lchiang → huang
Summary: Move message to IMAP folder loses message → [DOGFOOD] Move message to IMAP folder loses message

Updated

19 years ago
Assignee: phil → jefft

Comment 1

19 years ago
Reassign to jefft, cc bienvenu

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Updated

19 years ago
Whiteboard: [PDT+]

Comment 2

19 years ago
Data loss is bad, marking PDT+.

Comment 3

19 years ago
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.
(Reporter)

Comment 4

19 years ago
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

19 years ago
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

19 years ago
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,
(Assignee)

Comment 7

19 years ago
perhaps it's specific to the server, not the message.
(Reporter)

Comment 8

19 years ago
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?
(Assignee)

Comment 9

19 years ago
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

19 years ago
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.
(Assignee)

Comment 11

19 years ago
Since I reworking all the offline <-> online imap stuff, do you want to just
reassign this to me, Jeff?
(Reporter)

Comment 12

19 years ago
Created attachment 4145 [details]
Conversations with my IMAP servers.  Look for !!! - move message starts there

Comment 13

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

Updated

19 years ago
Assignee: jefft → bienvenu
Status: ASSIGNED → NEW

Comment 14

19 years ago
Off to bienvenu ...
(Reporter)

Comment 15

19 years ago
Created attachment 4147 [details]
complete session transcript
(Reporter)

Comment 16

19 years ago
Created attachment 4148 [details]
the message I tried to move
(Reporter)

Comment 17

19 years ago
Created attachment 4149 [details]
the message, this time without the rest of the mailbox
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
(Assignee)

Comment 18

19 years ago
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.
(Assignee)

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] 2/05/00
(Assignee)

Comment 19

19 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 20

19 years ago
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...
(Assignee)

Comment 21

19 years ago
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

19 years ago
Yes. I moved single message.

Comment 23

19 years ago
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

19 years ago
Marking as verified based on it's working fine for today's Linux Mozilla build.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 25

19 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 26

19 years ago
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

19 years ago
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?
(Reporter)

Comment 28

19 years ago
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?
(Reporter)

Comment 29

19 years ago
Created attachment 4818 [details]
mailbox before move
(Reporter)

Comment 30

19 years ago
Created attachment 4819 [details]
Mailbox after attempted to move first message
(Assignee)

Comment 31

19 years ago
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.
(Reporter)

Comment 32

19 years ago
Ok, then I'm marking this fixed again.  Do you want to file a bug against mscott
regarding the IMAP error not being caught?
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 33

19 years ago
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.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 34

19 years ago
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

19 years ago
OK. zach, then please don't open that bug. Thanks.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.