752423 - Localized special folder name of POP3 account is not shown in Tb 12, if special folder is created in English folder name by en-US Tb or by manual creation

Status: RESOLVED DUPLICATE of bug 759237

(Thunderbird :: Folder and Message Lists, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Build : Tb 12.0.1 release build. Same in Tb 12.0.1 ja & Tb 12.0.1 de.

(Phenomenon-1)
If special folder is created manually in English folder name by localized Tb 12(English name is mandatory to force English file name), it's impossible to use localized special folder name in Tb 12.
To show localized special folder name, one of next is needed.
(i)  Re-use Tb's profile by Tb 11. (.msf is written by Tb 11)
(ii) Delete panacea.dat, delete all .msf file of special folder, restart Tb 12.

(Phenomenon-2)
Once localized special folder name is shown at folder pane by a localized Tb 12(eg. Tb 12 ja, Tb 12 de, including Tb 12 en-US), localized special folder name of the first-use localized Tb is shown forever when same Tb's profile is used by localized Tb 12 of different localization.
To show localized special folder name of the different localization, one of next is needed.
(i)  Re-use Tb's profile by Tb 11. (.msf is written by Tb 11)
(ii) Delete panacea.dat, delete all .msf files of all pecial folders, restart Tb 12.

Both phenomena don't occur on special folder of "Local Folders".
(Checked with dummy POP3 account only. IMAP case is not checked.)
Both phenomena don't occur in Tb 11. Localized special folder name is always shown by simple restart of Tb 11.
If special folder is internally created by localized Tb 12 himself via. Archive operation, Save as draft, Mail send, Save as template, Manual/Filter Junk move, localized special folder name is shown since initial. So, Phenomenon-1 doesn't occur. However, Phenomenon-2 always occurs.    
This is reression by Tb 12 over Tb 11 or former.

Root cause looks "localized folder name is written in .msf file by Tb 12".

Comment 1

[WADA:World Anti-bad-Duping Agency]

Correction.
"Re-use of profile by Tb 11 en-US" seems needed to force clean-up.
(i) Re-use Tb's profile by Tb 11 en-US. (.msf is written by Tb 11 en-US)

Comment 2

[WADA:World Anti-bad-Duping Agency]

This bug is not observed on IMAP folders. Adding POP3 in bug summary.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

well, I'm bit confused. What is the difference from 'localized' and not 'localized'? In my understanding 'not localized' version is localized in en-US.

Anyway I have a fix for the issue in .msf, but is does not resolve this issue(i.e. the folder name stays localized in folder pane).  So the root causes is in cache file (panacea.dat).

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Maybe I was wrong..

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
 
> Anyway I have a fix for the issue in .msf, but is does not resolve this
> issue(i.e. the folder name stays localized in folder pane).  So the root
> causes is in cache file (panacea.dat).

I can not reproduce .msf issue without the fix at all...

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Now I can reproduce .msf issue when the test in bug 74909 runs.

In mailnews/local/src/nsLocalMailFolder.cpp:

1048 NS_IMETHODIMP nsMsgLocalMailFolder::SetPrettyName(const nsAString& aName)
1049 {
1050   nsresult rv = nsMsgDBFolder::SetPrettyName(aName);
1051   NS_ENSURE_SUCCESS(rv, rv);
1052   nsCString folderName;
1053   rv = GetStringProperty("folderName", folderName);
1054   NS_ConvertUTF16toUTF8 utf8FolderName(mName);
1055   return NS_FAILED(rv) || !folderName.Equals(utf8FolderName) ? SetStringProperty("folderName", utf8FolderName) : rv;
1056 }

To change mName to aName fixes the .msf issue, but I am not sure it is correct. Even if it is not correct, mName should be the name returned by nsMsgDBFolder::GetPrettyName()?

Comment 6

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)
> Now I can reproduce .msf issue when the test in bug 74909 runs.
> 
> In mailnews/local/src/nsLocalMailFolder.cpp:
> 
> 1048 NS_IMETHODIMP nsMsgLocalMailFolder::SetPrettyName(const nsAString&
> aName)
> 1049 {
> 1050   nsresult rv = nsMsgDBFolder::SetPrettyName(aName);
> 1051   NS_ENSURE_SUCCESS(rv, rv);
> 1052   nsCString folderName;
> 1053   rv = GetStringProperty("folderName", folderName);
> 1054   NS_ConvertUTF16toUTF8 utf8FolderName(mName);
> 1055   return NS_FAILED(rv) || !folderName.Equals(utf8FolderName) ?
> SetStringProperty("folderName", utf8FolderName) : rv;
> 1056 }
> 
> To change mName to aName fixes the .msf issue, but I am not sure it is
> correct. Even if it is not correct, mName should be the name returned by
> nsMsgDBFolder::GetPrettyName()?

Ah, I might misread the code. The mName implies that we need to use 'pure name' instead of pretty name? Then, to use aName is reasonable here.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Attachment: Possible fix

The root cause is that SetFlagsOnDefaultMailboxes() does not invoke if those special folders already exist.

SetFlagsOnDefaultMailboxes() does finally invoke SetPrettyName so that those localized name are set correctly on each time Thunderbird started.

Though nsMsgLocalMailFolder::GetSubFolders and DiscoverSubfolders have redundant codes, I will fix it in bug 756316.

Comment 8

[WADA:World Anti-bad-Duping Agency]

This bug was not special folder only issue.

(Phenomenon-3)
If FileA/FileA.msf(string of File-A is written in .msf) is manually copied to FileB/FileB.msf(string of File-A is still written in FolderB.msf), FolderA is shown at folder pane for both mail folder file, and is saved in panacea.dat once FolderB/FolderB.msf is shown as FolderA.
  Folder Pane(panacea.dat data)  folder file  msf file      string in .msf
   FolderA                        FolderA      FolderA.msf    FolderA
   FolderA                        FolderB      FolderB.msf    FolderA

Because folder file name is used in internal path of folder, and the internal path is writte in msgFilterRules.dat, problem perhaps won't usually occur even though FolderA is shown for FolderB/FolderB.msf.
However, FolderA is shown at messae filter rule panel. So it surely produces user's confusion.

If non-special folder, this situation is recovered by "rename to FolderX, then rename to FolderB", but if special folder of Inbox, Trash, delete panacea.dat/restart Tb is needed to recover from bad folder pane display.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(Phenomenon-3, continued)
(1) Folder Name = FileA : FileA/FileA.msf(string of File-A is written in .msf)
(2) Copy FileA/FileA.msf to FileB/FileB.msf and FileC/FileC.msf.
    String of "FileA" is written in FileB.msf and FileC.msf too.
(3) Folder Pane         Folder file   msf file      string in .msf
    (panacea.dat data)
     FileA               FileA         FileA.msf     FileA
     FileA               FileB         FileB.msf     FileA
     FileA               FileC         FileC.msf     FileA   
(4) Rename FileA(set of FileA/FileA.msf) to FileX1.
    Set of FileC/FileC.msf is changed to Folder Name=FileX1, FileX1/FileX1.msf
(5) Rename FileA(set of FileA/FileA.msf) to FileX2.
    Set of FileB/FileB.msf is changed to Folder Name=FileX2, FileX2/FileX2.msf
(6) Rename FileA(set of FileA/FileA.msf) to FileX3.
    Set of FileA/FileA.msf is changed to Folder Name=FileX3, FileX3/FileX3.msf

This is due to that "rename" is perhaps next;
  Folder Name = FileA => no need to hash file name, then File Name = FileA
  => internal path with "FileA" is used by rename
  => search seems reversed alphabetic order
  => set of FileC/FileC.msf is selected at rename to FileX1,
     set of FileB/FileB.msf is selected at rename to FileX2.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 625016 [details] [diff] [review]
Possible fix

Clearing review request because I just post a properer fix to nsIMsgPluggableStore.discoverSubFolders in bug 759237.

Comment 11

[Ludovic Hirlimann [:Usul]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #10)
> Comment on attachment 625016 [details] [diff] [review]
> Possible fix
> 
> Clearing review request because I just post a properer fix to
> nsIMsgPluggableStore.discoverSubFolders in bug 759237.

so this bug is fixed by 759237 ?

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I'd say that localized folder case has been fixed by the fix for bug 759237. But WADA mentioned about non-localized folder case in comment #8.

Comment 13

[Ulf Zibis]

Attachment: screen shot

I have same phenomenon on POP3 Drafts folder, but I never created it manually.
But I have deleted panacea.dat some days ago to fix a naming problem in another IMAP account.
Now I'm thinking about deleting Drafts.msf.
To feel secure, please first answer:
- am I loosing any info while deleting Drafts.msf, especially are my colouring tags lost?
Please answer briefly.

Comment 14

[David :Bienvenu]

(In reply to Ulf Zibis from comment #13)
> Created attachment 631466 [details]
> screen shot
> 
> I have same phenomenon on POP3 Drafts folder, but I never created it
> manually.
> But I have deleted panacea.dat some days ago to fix a naming problem in
> another IMAP account.
> Now I'm thinking about deleting Drafts.msf.
> To feel secure, please first answer:
> - am I loosing any info while deleting Drafts.msf, especially are my
> colouring tags lost?
> Please answer briefly.
Most likely not. Why not move the Drafts.msf file to a different directory, restart, and see if your tags are still there. If not, you can shutdown, and copy the saved Drafts.msf file back.

Comment 15

[Ulf Zibis]

Thanks!
I also rescued Drafts to have a valid pair.
Yes, the tags were save :-)

So I deleted panacea.dat + Drafts.msf while shutdown, but after restart, the english named folder label was still there. :-(

Wondering: I was not added automatically to the cc list after my first comment here.

Comment 16

[Ulf Zibis]

Since I have updated to TB 13 the german label is again correct: "Entwürfe"

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to Ulf Zibis from comment #15)
> So I deleted panacea.dat + Drafts.msf while shutdown, but after restart, the
> english named folder label was still there. :-(

As I already wrote, "delete .msf of all special folders" is needed. It means that "delete of .msf of special folder on which problem was seen only" is not a correct recovery operation.

(In reply to Ulf Zibis from comment #16)
> Since I have updated to TB 13 the german label is again correct: "Entwürfe"

It's not surprizing because "status-thunderbird13: fixed" is already set in Bug 759237. Read commenr #12, please.

Comment 19

[WADA:World Anti-bad-Duping Agency]

(In reply to Ludovic Hirlimann [:Usul] from comment #18)
> *** This bug has been marked as a duplicate of bug 759237 ***

Ludo, have you verified that my comment #8 case of this bug is also fixed by fix of that bug?

Comment 20

[Ludovic Hirlimann [:Usul]]

(In reply to WADA from comment #19)
> (In reply to Ludovic Hirlimann [:Usul] from comment #18)
> > *** This bug has been marked as a duplicate of bug 759237 ***
> 
> Ludo, have you verified that my comment #8 case of this bug is also fixed by
> fix of that bug?

NO I had missed that.