567716 - If mail is moved multiple times while offline mode, only first move is done upon Work Online, thus mail in final destination is lost

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Attachment: IMAP log with Leak Gauge log

Log was obtained with next parameter.
> SET NSPR_LOG_MODULES=timestamp,imap:5,ImapAutoSync:5,IMAPOFFLINE:5,MsgPurge:5,MSGDB:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5

This is spin-off of Bug 433806 Comment #37, (Phenomenon-A).

If mail is moved multiple times while offline mode, only first move is done upon Work Online, thus mail in final destination is lost.

[Build ID]
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100513 Shredder/3.2a1pre

[Steps to reproduce]
(0) Gmail IMAP
    IMAP delete model : remove immediately
    Max cached connection count : 2
    auto-compact is enabled, so dialog before auto-compact is enabled to test.
    As dialog before auto-compact appeared, I replied "No"(or "Cancel").
    Folders: a1,a2,a3 (no mail)  a4 (10 small text/plain mails)
             offline-use=off, for quick check
(1) Work Offline.
(2) Move mails while offline mode
(2-1) Move  5 mails from a4 to a3
(2-2) Move  5 mails from a4 to a2
(2-3) Move  5 mails(all mail) from a3 to a1
(2-4) Move  5 mails(all mail) from a2 to a1
(2-5) Move 10 mails(all mail) from a1 to a4
(3) Keep backup of a1.msf, a2.msf, a3.msf, a4.msf 
(3) Work Online
    5 mail were moved from a4 to a2, 5 mails were moved from a4 to a2
    move from a2/a3 to a1 and move from a1 to a4 was ignored.
    => mails in final destination(a4 in this test) is lost.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Attachment: a1.msf just before Work Online

Comment 2

[WADA:World Anti-bad-Duping Agency]

Attachment: a2.msf just before Work Online

Comment 3

[WADA:World Anti-bad-Duping Agency]

Attachment: a3.msf just before Work Online

Comment 4

[WADA:World Anti-bad-Duping Agency]

Attachment: 4.msf just before Work Online

Comment 5

[WADA:World Anti-bad-Duping Agency]

Order of uid copy, uid store is as follows.
> 00002368 15:38:30.815 (snip) S-A/a2:SendData: 8 uid copy 1:5 "A/a1"
> 00002371 15:38:31.112 (snip) S-A/a2:SendData: 9 uid store 1:5 +FLAGS (\Deleted \Seen)
> 00002484 15:38:33.643 (snip) S-A/a3:SendData: 8 uid copy 1:5 "A/a1"
> 00002487 15:38:33.846 (snip) S-A/a3:SendData: 9 uid store 1:5 +FLAGS (\Deleted \Seen)
> 00002567 15:38:34.940 (snip) S-A/a4:SendData: 17 uid copy 123:127 "A/a3"  
> 00002637 15:38:35.830 (snip) S-A/a4:SendData: 20 uid copy 128:132 "A/a2"  

(Problem-1) order of copy was reversed. a2->a1, a3->a1, a4->a3, a4->a2
            re-execution of move is done based on move source folder name?
(Problem-2) last move from a1 to a4 was lost.
(Problem-3) Gmail IMAP returns OK even though mail of specified UID doesn't
            exist in a2 and a3 at the steps.
  Note: I renamed folders before test like next.
        - rename to a1, a2, a3 while no mails, so UID starts from 1
        - rename to a4 while 10 mails exist after move/delete tests,
          so UID started from 123 for a4.

Comment 6

[WADA:World Anti-bad-Duping Agency]

If mail of uid 1:5 is created in a2/a3 by other client while this Tb is running, mails in a2/a3 is wrongly moved to a1 and deleted from a2/a3 by this Tb.
Problem-1/2 and problem-3 is independendent.

Comment 7

[Mark Banner (:standard8)]

Sorry, wrong bug.