219401 - move/copying imap messages with bodies downloaded for offline use don't have their bodies moved to offline store of dest folder

Status: RESOLVED DUPLICATE of bug 439108

(MailNews Core :: Networking: IMAP, enhancement)

Description

[Stefan Magdalinski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030910


this morning I tried to move my entire inbox (about 400 messages) into a
different folder. I selected all, and then used the context menu to move them to
the new folder.

The operation appeared to complete successfully, but when I went looking later
the  inbox was empty, but the messages had NOT appeared in the new folder.

I just lost 13 days of mail.

I have an IMAPlog, but I can't attach it because it's 6 Mb zipped.

I'm not going to try and reproduce this in a hurry.

Reproducible: Didn't try

Steps to Reproduce:

Comment 1

[David :Bienvenu]

*** Bug 219402 has been marked as a duplicate of this bug. ***

Comment 2

[David :Bienvenu]

Stefan, please send me a log. This is a move between two imap folders on the
same server?

Comment 3

[Stefan Magdalinski]

confirmed. I suspected for a while that I'd just deleted them, but then they'd
be in the trash, right? (sorry for the dupe, that's what happens when you file
bugs while watching The West Wing :) )

log in the mail.

Comment 4

[David :Bienvenu]

this turns out to be an RFE - when you move/copy an imap message which has its
body downloaded for offline use, and the dest folder is configured for offline
use, we should copy the offline message body to the offline store for the dest
folder. The reason we don't do this is that we don't know the uid of the message
in the dest folder so we can't really add the header or the offline message
body. As Stefan points out, we could sync the dest folder after the move/copy,
though this can be a heavyweight operation. One idea is to have a pref that says
"always keep offline stores in sync, even though it can be slow", so that there
would be two modes of operation - automatic offline sync, and the explicit
offline sync we currently have.

Comment 5

[Steve Hollingsworth]

It may well be that SOME aspects of this problem are RFE, but this bug appears to manifest itself in all kinds of obnoxious ways.  And in no way is this just a Windows thing.  I discovered the issue and found this bug running Ubuntu Linux.

For example, I created a filter for my IMAP account that appears to work but can end up losing data if you do not discover the problem in time.

Create a filter for your IMAP account with these steps:

If message is >1MB then
- copy message to Inbox on Local Folders
- move message to Trash on IMAP account

In this event, the copy fails silently, but the move is executed.  Depending on how the IMAP account handles trash, then you may lose the message irretrievably.

Fixing something that allows data to be lost silently CANNOT be an RFE!

Comment 6

[David :Bienvenu]

I fixed this in bug 439108