742072 - When moving messages from IMAP directory(Offline-use-On) to local directory, Thunderbird deletes the messages even when copy phase is not successfull due to network error, resulting in data loss

Status: RESOLVED DUPLICATE of bug 522675

(MailNews Core :: Networking: IMAP, defect)

Description

[winterknight]

I use IMAP to sync my mail. I tried to move some older messages to a local archive folder. There were about 20 messages total. Thunderbird successfully moved 2 messages, but the rest failed, probably due to the unreliable internet connection I was using. Despite failing the move operation, Thunderbird deleted all of the messages from the IMAP folder, and so now most of them are gone forever.

Any time you are doing a move operation, whether it involves local files, remote, or a combination, you should never delete the original files before they are written to the destination.

Comment 1

[Hashem Masoud]

(In reply to winterknight from comment #0)
See bug 591712.

Comment 2

[Wayne Mery (:wsmwk)]

winterknight, do you find bug 591712 comment 1 to be true for you?

"the unsuccessful move operations can be successfully undone by using the 'Undo' feature from the 'Edit' menu or by pressing the 'Undo' hotkey (ctrl-z in Windows) as long as Thunderbird has not been closed since the operation."

Comment 3

[David :Bienvenu]

the subject is not true - the messages are copied first, and after that succeeds, the originals are deleted. If this is happening, it must be that the check to see if the copy succeeds isn't detecting the failure somehow. It's hard to imagine how a delete, followed by a move would ever work...

Do you have your imap folders configured for offline use? By "unreliable internet connection", you mean to the imap server, right, so the failure would be trying to download the message from the server, not the writing to the local folder?

Comment 4

[winterknight]

@Wayne Mery: I don't know if that would have worked. I guess I should have tried it.

@Davie Bienvenu: Yes, the IMAP folders are configured for offline use. The unreliable connection is the imap server. The local folders were on the local hard drive.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to David :Bienvenu from comment #3)
> the messages are copied first, and after that succeeds, the originals are deleted.

Bug 522675 is for "bulk move from IMAP to Local" case and bug opener reported similar phenomenon/problem to this bug.
Bug 522675 commnt #5 is a test result of "intentional Pull off of LAN cable while copying(fetching) big mail by move of a big mail from Gmail IMAP(Offline-use=Off) to Local". Because of "Pull off of LAN cable", Offline status is automatically detected. In this case, Tb issued "uid store flags \Deleted" for the mail after reconnection of LAN cable(Online status is automatically detected), even though network error occurred while fetching and copy phase is not successful.

Bug 624082 is for "bulk move from IMAP to same IMAP"(special "move A to B & "move A to C at same time" case though), and bug opener reports "delete at move source IMAP folder for not-copied mail. In this case, cause of error while bulk copy phase is perhaps interfere of fetching from A(for "move A to B") by fetch request for other move("move A to C").

Bug 693353 is for interesting "NO to append command by Detatch" case. The "NO to append" in this case is "too old mail's timestamp to append", because old mail is uploaded by Detach and Tb uses timestamp of Date: header and server has limitation in mail's timestamp in append command. In this case, Tb continued to send mail data until end of data even after NO to append and BAD for subsequent data sending, and after re-login, Tb issued "uid store flag \Deleted" for UID of original mail of Detach even though append of new version(Detach'ed mail) failed.

In any case, error during copy phase is not handled well, and Tb goes ahead to delete phase even though copy phase fails.

Comment 6

[WADA:World Anti-bad-Duping Agency]

changing bug summary(remove not-true part) to avoid confusion.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Bug 720158 is for "hang at mid of copy phase of bulk move from IMAP to IMAP.
Bug 720158 comment #13 is a test result by intentional pull off of LAN cable with next condition for problem of Bug 720158.
 - bulk move from IMAP(offline-use=On, sync'ed) to different IMAP(offline-use=On)
 - move of 1000 small mails
 - pull off LAN cable when 10 mails are copied
In this case, fetch command was not issued and append to move target IMAP only was seen, and "bulk move of 1000 mails" silently ended at "successfull copy of 10 mails". Nothing other occurred.

Tb possibly doesn't consider "network error/NO or BAD response to fetch BODY[] command during fetch request by bulk copy phase of bulk move" as "error during copy phase".

Comment 8

[Hiroyuki Ikezoe (:hiro)]

I can tell this is a duplicate of bug 522675.