1720202 - Don't preserve offlineMsgSize parameter when move/copy emails between folders

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: General, defect)

Description

[Dmitry Butskoy (:buc)]

The "offlineMsgSize" parameter should be added to "mailnews.database.summary.dontPreserveOn{Copy,Move}" to avoid possible corruption of imap offline database and incorrect display of emails.

Comment 1

[Dmitry Butskoy (:buc)]

During the "imap folder --> local folder -->imap folder" movement of an email, the "offlineMsgSize" extra parameter will appear in the "local folder", and then will be moved into "imap folder" again. It can lead to potential issues, since the actual size of the local mail is always changed (due to adding of "X-Mozilla-Keys" header etc.), but this sparameter does not reflect this.

Besides that, accroding to the code, the presence of "offlineMsgSize" causes a wrong "msgOffset" parameter's value (matches the offset in the local folder) to be stored in the imap offline data. If such an offset matches an offset of the existing imap email (or a slot of a removed email), the wrong data is shown for such email.

To resolve the issue, "offlineMsgSize" should be added to "mailnews.database.summary.dontPreserveOnCopy" and ""mailnews.database.summary.dontPreserveOnMove" preferences.

Fortunately, it seems that bug #1430480 fixes this issue too, in a more common and robast way. What became clear while this message was being written... :)

Comment 2

[Dmitry Butskoy (:buc)]

This issue was most easily reproduced when msgOffset was zero. (Two different folders always have slots with the same zeroed msgOffset - their first slots). To provide zero msgOffset, the folder should be emptied and compacted, or just created.

On tests with creation of the folder yet another issue was found.
Consider you completely remove ImapMail/ from your profile. On the next run, it will be recreated, but in a wrong form:

ImapMail/<server>.sbd/INBOX
ImapMail/<server>/Sent
ImapMail/<server>/Trash
...

Note another subdir for INBOX. The code assumes that the root folder to be created is kinda imap subfolder, and adds ".sbd" suffix to it.

On the second run, seeing ImapMail/<server>, but not seeing INBOX in it, yet another INBOX appears now in the right place ImapMail/<server>/INBOX.
Two different INBOX locations lead to mess.

This issue is normally not happen on practice, because ImapMail/<server/ is always pre-created at the account creation stage.

To fix it, just one more test for isServer flag is needed:

--- comm/mailnews/base/util/nsMsgDBFolder.cpp.orig      2021-05-25 21:36:20.000000000 +0300
+++ comm/mailnews/base/util/nsMsgDBFolder.cpp   2021-07-09 21:03:53.266796854 +0300
@@ -3900,15 +3900,17 @@ nsresult nsMsgDBFolder::CreateDirectoryF

   if(!pathIsDirectory)
   {
-    //If the current path isn't a directory, add directory separator
-    //and test it out.
-    rv = AddDirectorySeparator(path);
-    if(NS_FAILED(rv))
-      return rv;
-
-    //If that doesn't exist, then we have to create this directory
-    pathIsDirectory = false;
-    path->IsDirectory(&pathIsDirectory);
+    if(!isServer) {
+      //If the current path isn't a directory, add directory separator
+      //and test it out.
+      rv = AddDirectorySeparator(path);
+      if(NS_FAILED(rv))
+        return rv;
+
+      //If that doesn't exist, then we have to create this directory
+      pathIsDirectory = false;
+      path->IsDirectory(&pathIsDirectory);
+    }
     if(!pathIsDirectory)
     {
       bool pathExists;

Comment 3

[Dmitry Butskoy (:buc)]

Ian,

Could you pls consider whether this "related" issue bug #1720202 comment #2 is rare enough case, or it should be actually fixed...

Comment 4

[Frank-Rainer Grahl (:frg)]

Fixed for 2.53.8.1 and up by backporting Bug 1430480

https://gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/commit/05cbfe6e06043e2230eb2aa78bcfcc49d9e01f46
Fix missing message parts when messages copied manually or filtered. r=jorgk