1989670 - weird folder name (e0a68269) has appeared in the folder view: no mail in the folder

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Ian Graham]

A weird mail folder with the name "e0a68269" has appeared in the Local folders view in Thunderbird. I have no idea where it came from. The folder seems to contain no mail, but I can't delete it: when I do it just magically reappears when I restart thunderbird.

When I look in ~/Library/Thunderbird/Profiles/fh2ko847.default/Mail/Local Folders/" I see the following files:
-rw-------@ 1 iangraham staff 0 Sep 19 17:52 e0a68269
-rw-r--r--@ 1 iangraham staff 2004 Sep 19 19:11 e0a68269.msf

This happened when I deleted one of my email folders with the name ".Project-23'. Could it be something to do with having a period as the first character in teh folder name? (did this to keep the folder at the very top of the folder list...)

As far as I can tell there is no dataloss, but I have too many folders to know for sure ......

Comment 1

[Magnus Melin [:mkmelin]]

When the file system didn't allow the name in question, such a hash is used. .Project-23 should be fine though.

Comment 2

[Ian Graham]

Thanks Magnus. I think I will need to update this to a dataloss issue: by checking around I realize one of my previously existing Local Folders (named ".Massey_college") disappeared around the time the weird folder ("e0a68269") appeared in Thunderbird's Local Folders list.

But the "e0a68269" is empty - does not contain any mail messages (when I select the folder the mail list view says "No message found"). and when I do a search across all of "Local Folders" (and subfolders in it) I cannot find any of the messages I put in the ".Massey_college" folder.

Further, when I now try to 're-create' a folder with the name ".Massey_college" : Thunderbird gives the message:
Error - on Local Folders
A folder with that name already exists. Please Enter a different name.

So something is weirdly broken.....

Comment 3

[Ian Graham]

Note that for me there is no explicit dataloss, as I still have the messages in the mail server's archives folder. But this problem is annoying, and will confuse someone who does not understand mail clients / client-mail server protocols well.......

Comment 4

[Brendan Abolivier [:babolivier]]

(In reply to Magnus Melin [:mkmelin] from comment #1)

When the file system didn't allow the name in question, such a hash is used. .Project-23 should be fine though.

Looks like we do consider a period an illegal character when it's the first character of the folder name: https://searchfox.org/comm-central/rev/ed9d90545a16aa6944c317b4ece50f08e2d0d560/mailnews/base/src/nsMsgUtils.cpp#99

So, under that rule, ".Project-23" does trigger the hashing logic. We also seem to rule trailing spaces at the end of a folder name illegal, which causes bug 1990761.

It looks like NS_MsgHashIfNecessary works by keeping everything before the first illegal character, and replacing everything after that character (including the illegal character itself) with a hash: https://searchfox.org/comm-central/rev/ed9d90545a16aa6944c317b4ece50f08e2d0d560/mailnews/base/src/nsMsgUtils.cpp#301-314

Which would be why the entire name is replaced with a hash. If I create a local folder with the name ".Massey_college", it's indeed automatically renamed into "e0a68269".

Comment 5

[Brendan Abolivier [:babolivier]]

Note that this doesn't seem to affect IMAP (I assume that's because IMAP does pretty much its own thing with regards to disk management compared to other protocols). I'm able to create a folder ending or starting with a period without any issue (though it looks like it just won't create a folder with a trailing space at the end of the name). The resulting folders on disk do look hashed (e.g. .foo gets 59dcdc9b.msf), but the displayed name stays human-readable.

At a glance I'd say this happens to every protocol that creates folders via nsIMsgPluggableStore::CreateFolder, which it looks like almost every protocol but IMAP does (including local folders).

Comment 7

[Eleanor Dicharry]

I thought this might have been caused by one of my recent dangling folders patches, so I investigated. It wasn't, but I think I found the issue and I'm putting together a patch.

Comment 8

[Richard Leger]

It may be time for the Thunderbird team to look at all the folder name issue reported over the years, as per meta Bug 124287, and tackle them all at ones, and for all, for all types of account.

I also found this guideline to workaround Outlook synchronisation issue with IMAP account, may be worth checking that Thunderbird is not affected by any of those as well! While at it...
https://www.uk.forgetaboutit.net/wiki/index.php/How_to_prevent_Outlook_2016/2019_IMAP_sync_issues

Comment 9

[Richard Leger]

As posted here https://thunderbird.topicbox.com/groups/android-beta/T17d8a14f58b5ddeb-M980a606af9e3d269d5905e3b also to take in consideration for escaping special characters in folder names upon new folder creation:

"...
Some IMAP servers use a dot (.) as a folder separator, while others use a slash (/). The specific separator is an implementation detail of the IMAP server.

Why Separators Differ 🤷‍♀️
The IMAP protocol itself doesn't mandate a specific folder separator. This leads to different server software using different conventions.

• Dot-based separators are common in older systems and those using the Maildir storage format, which often represents subfolders by adding a dot to the parent folder's name (e.g., INBOX.Sent).

• Slash-based separators are popular because they align with the directory hierarchy used in file systems like Unix/Linux. Servers like Dovecot and Cyrus IMAP often use a slash as their default or can be configured to do so.

How Clients and Servers Handle It 🤝
When an email client connects to an IMAP server, it can determine the correct separator by issuing a LIST command. The server's response includes the hierarchy separator it uses. The client then uses this information to correctly display and manage the folder tree.
..."

Comment 10

[Eleanor Dicharry]

The local folders part of this issue was regressed by the removal of this line. There is still an additional problem with ews folders, so I'm going to try and fix them both together with a single change and without reintroducing the regressing change's deleted lines.

Comment 11

[Eleanor Dicharry]

Attachment: Bug 1989670 - Ensure the database name of new folders is set correctly. r=#thunderbird-back-end-reviewers

Comment 12

[Eleanor Dicharry]

This patch Fixes the creation issue, but there's still an issue with EWS reverting the displayed names of the folders to hashes following a restart. I'll handle that part in a separate patch.

Comment 13

[Eleanor Dicharry]

I think the follow-on EWS-only problem deserves its own issue, so I filed bug 1992283 to track it separately.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9efa4f2d1473
Ensure the database name of new folders is set correctly. r=BenC