Empty Mbox/cur/nnnn directory is created by first mail copy from MaildirStore/IMAP/Offline-Use=On folder, if Mbox directory and Mbox/cur directory is not created yet

RESOLVED DUPLICATE of bug 1017939

Status

defect
RESOLVED DUPLICATE of bug 1017939
7 years ago
5 years ago

People

(Reporter: World, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
x86
Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [maildir])

+++ This bug was initially created as a clone of Bug #857436 +++

[Build ID]
> Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Thunderbird/22.0a1
> Application Build ID : 20130325031104

Empty Mbox/cur/nnnn directory is created by first mail copy from MaildirStore/IMAP/Offline-Use=On folder, if Mbox directory and Mbox/cur directory is not created yet.
This problem was found during setups for test of bug 857003 and bug   857436.

[Steps to reproduce]
(1) Create Maildirstore/IMAP/Offline-Use=Off folder, call Mbox.
    => Mbox.msf is created.
(2) Change Mbox to Offline-Use=On.
    => Mbox directory, Mbox\cur directory, Mbox\tmp directory,
       is not created yet.
(3) Copy a mail to Mbox from MaildirStore/IMAP/Offline-Use=On folder
    => msgDBHdr is copied to Mbox.msf,
       and mail is shown at thread pane.
(4) Click mail.
    => Mbox directory, Mbox\cur directory is created.
    => Empty Mbox/cur/nnnn is created.

Once this "empty Mbox/cur/nnnn" is generated in MaildirStore/IMAP/Offline-Use=On folder, the "empty Mbox/cur/nnnn" is easily propagated to other MaildirStore/IMAP/Offline-Use=On folder and MaildirStore/LocalMbox by simple "Mail Copy", even by "step by step copy", "copy one mail per one copy operation".

I believe that cause of this kind of problem is usually lack of "file/directory existence check", "file or directory check", "file size check" etc., and lack of "error return code/error status check" in many places of Tb's code.
Patch by bug 674742 is a n example of sorting out work done in "Compact of BerkleyStore" to resolve data loss problem like bug 498814 and its dups.
No longer depends on: 857436
Depends on: 856387
Blocks: 859011
No longer blocks: maildirblockers
I believe that the changes that I did to nsMsgMaildirStore::GetMsgInputStream in bug 1017939 addressed the cause of this. If not, feel free to reopen.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1017939
You need to log in before you can comment on or make changes to this bug.