Closed Bug 1990571 Opened 7 months ago Closed 5 months ago

Thunderbird 143 – Local Folders: newly created subfolders disappear after restart, existing subfolders not displayed

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
Thunderbird 143
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
147 Branch

People

(Reporter: gaianorm, Assigned: edicharry, NeedInfo)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [regression v142 -> v143])

Attachments

(1 file)

Bug 1990571 - Continue traversal of a parent folder when a sub-hierarchy fails. r=#thunderbird-back-end-reviewers
48 bytes, text/x-phabricator-request
Details

Steps to reproduce:

Open Thunderbird 143 on Windows 11.

Go to Local Folders and create a new folder or subfolder.

Close Thunderbird completely.

Reopen Thunderbird.

Actual results:

The newly created folder is no longer displayed in the folder pane.

Existing subfolders physically present in the profile directory (Mail\Local Folders... .sbd) are not shown in the Thunderbird UI.

Expected results:

New folders created under Local Folders should remain visible after restart.

Subfolders present on disk should always be displayed in the folder pane.

Additional Information

The issue occurs consistently on Thunderbird 143.

Downgrading to Thunderbird 142 resolves the issue (folders and subfolders are correctly shown).

Profile structure is correct:

Each folder exists as an mbox file (no extension) with corresponding .msf index.

Subfolders are stored in .sbd directories.

Permissions and paths are correct; tested on %APPDATA%\Thunderbird\Profiles[profile]\Mail\Local Folders.

Possibly related to regression in Local Folders handling introduced between 142 and 143.

Anything in the Error Console? (Ctrl+Shift+J)
Did you try Help | Troubleshoot mode?

Keywords: regression, regressionwindow-wanted
Whiteboard: [regression v142 -> v143]

gaianormo, please reply. Thanks

Flags: needinfo?(gaianorm)

Anje, Corey do we have other reports of this in SUMO + bugzilla?

Flags: needinfo?(corey)
Flags: needinfo?(anjeyelf)

I've not seen anything on bugzilla

Flags: needinfo?(corey)

Using Windows 11 OS - Logon to user account (not MS account)
Tested using beta 144.0b2
Language: English British
Profile in default location User/Username/Appdata/Roaming/Thunderbird etc
No addons installed.

Created a new folder in 'Local Folders' called 'BugTest'
Exit and Restart Thunderbird.
Actual and Expected Result:
'BugTest' folder is displayed.

created a new subfolder in 'BugTest' called 'sub bugtest'
Exit and Restart Thunderbird.
Actual and Expected Result:
'BugTest' folder is displayed containing subfolder 'sub bugtest'

I'm not able to reproduce this bug.

Flags: needinfo?(anjeyelf)

I'm wondering if the issue maybe related to Long Path names in Windows OS where the default maybe 260 characters.

This could happen if folders have a deeper hierarchy - subfolders etc.

But it does seem odd that a Thunderbird update should cause a problem assuming there is no change in the folder structure.

I also cannot reproduce this. I am using 143.0.1 with win 11.

For people affected, do check the long path name theory.
I don't see anything changed around that, but from at least some of the reports above, it seems likely they had deep hierarchies with long folder names.

Two cases in the French Mozilla Thunderbird forum https://forums.mozfr.org/viewtopic.php?t=157424
Both could be solved by a downgrade to v141

I step into this issue with Thunderbird v143. I find this report on reddit (https://www.reddit.com/r/Thunderbird/comments/1nulms7/thunderbird_14301_deleting_many_local_folders/), already mentionned in this thread.

Rollback to thunderbird v142 brings back all missing folders.

It is not my personal mailbox, so I cannot easily provide further feedback, but here are my feedback :

  • my use-case is with Thunderbird / Windows 10
  • some folders are missing, other aren't
  • this mailbox contains a deep folder hierarchy, with long folder names
  • it seems that thunderbird stops folder traversal when it encounters a problematic folder : problematic folder is shown emptu, all the folders following this folder are missing
  • copying the local folders data in a new profile does nothing (the same folders are missing)
  • removing the first empty folder seems to allow thunderbird to show some folders, until it steps again into a problematic folder, shown empty, and the following folders are missing
  • folder repair does nothing
  • troubleshoot mode does nothing
  • rollback to v142 brings back all the missing folder

I'll try to Ctrl+Shift+J to collect logs when I can access again this mailbox.

Some more feedback since my previous message : with Thunderbird v142, ctrl+shift+j shows file access errors that seems consistent with a file path length issue.

This file access errors disappears when I rename some intermediate folders to shorten the file path.

It seems to be that there is a behavior change between Thunderbird 142 and Thunderbird 143 when it hits a file path length problem :

  • Thunderbird 142 emits an error, the problematic folder is broken, but other folders are unaffected
  • Thunderbird 143 ignores remaining folders (at least on display) when there is a problematic folder

Sadly, I don't have enough time to perform the Thunderbird 143 update to see if the path length fix resolves the issue for this mailbox.

I have a reproducer test-case :

  • Thunderbird v142.0 : new empty profile, create a mail account (it doesn't need to be valid)
  • In local folders : create folder cc
  • (A). In local folders : create folder aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (30*a)
  • (B). In previous folder : create aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (30*a)
  • (C). In previous folder : create aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (30*a)
  • (D). In previous folder : create aaaaaaaaaa (10*a)
  • (E). In previous folder : create aaaaaaaaaa (10*a)
  • (F). In previous folder : create aaaaaaaaaa (10*a)

You now have:

  • (A) -> (B) -> (C) -> (D) -> (E) -> (F)
  • cc
  • Rename (D) to aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (30*a) ; change is accepted and displayed
  • Stop and restart Thunderbird : (D) folder goes back to its previous name (10*a) ; cc is still present
  • Stop and upgrade to Thunderbird 143.0.1
  • Start Thunderbird : cc disappears, (F) disappears
  • Go back to Thunderbird v142.0, start with -allow-downgrade
  • Start Thunderbid : cc and (F) are back

I suppose that the folder structure needed to reproduce may depend on thunder profile location (as full path length may vary).

Starting to see more reports in Support:
https://support.mozilla.org/en-US/questions/1543783

Using Thunderbird 145.0, Windows 11 Pro.

Same issues reported as above... a few seemingly random sub-folders appearing and disappearing in Local Folders.

C::\Users\xxxxx\AppData\Roaming\Thunderbird\Profiles\m3dxnkxe.default-release\Mail\Local Folders\current customers.sbd

I can see the files in the folder on disk in the above location:

xrxntxixe
xrxntxixe.msf

Move the two above files into a new inbox sub-folder and you see the folder.

Really odd. Never been an issue until some recent update.

I can confirm this has been an issue for me since 143.0 was introduced. 145.0 still has the issue. Luckily I have nightly backups and so can restore back to 142.0. I notice the issue after an upgrade. But creating a new, deeply nested folder also causes the problem in the later versions.

It likely is a long path name on Windows problem. The mail folders are all still there. Just very few display in TB after restart. For me, I keep all mail for all accounts in Combined / Local Folder. it just so happens, apparently the 2nd mail folder it is trying to process at startup is very deeply nested with many subfolders; many with long names. It never makes it past that 2nd top level folder. As a result, even the Inbox, Drafts, Sent, etc standard folders are not displayed either. I did not see a way to attach screenshots of the folders for 142.0 (complete) and 143.x-145.x (truncated). When I look in "modified date" order at the Local Folders file structure after upgrading , only the displayed folders have been modified. I cannot show path names here as the folder names are including personal names and other private information. I can have both versions installed to experiment further, if needed. But I think the issue was recreated above. I happen to use the PortableApps version of TB on Windows 11 Preview.

Thanks for your input. To test this theory, if you copy the whole profile folder into a much shorter path location and open that profile, does everything show as expected?

(you can use a command-line switch to specify a profile location e.g. -profile "C:\tbprofiles\12345678.Profile Name"

Flags: needinfo?(reharr)

My path to the installation and profile is pretty small. So instead, I removed the likely offending top-level mailbox (that has deep nesting and long names for folders inside it), upgraded, and all the rest of the folders now appear as normal. Note that it is not my largest mailbox folder structure by size (3.8 GB vs two large than that). But is the deepest nesting and long names for each level. If I add the folder back under the profile/Mail/Local Folders, it is back to when I normally did an upgrade. All the folders (including Inbox, Sent, etc) missing except for a few in that offending top level one. I can go back in and add subfolders one by one. With some, everything is there as normal. With others, I am missing most everything. I am looking to see if I can use Directory Lister or similar to give me a list of the paths sorted by longest to shortest to see if it is consistent to path length. Although sometimes the folders get cryptically named by TB -- different than the name I visually see in the interface. So not yet sure if the folder path on the disk or the UI length is what makes the difference. Will see what time I can devote to further experiment.

Flags: needinfo?(reharr)

I gave in comment 16 a step by step reproducer to trigger the issue from a clean profile.

Observations are the same than the one reported lately : windows issue, deep folder structure, long paths, disappearing folders, works fine with 142, broken when updated to 143, fixed if downgraded to 142.

I just see I forget to provide some insight : issue encountered on windows 10 home, and reproducer prepared on windows 11 home.

Got it, most helpful - thanks!

Eleanor, could your patch for bug 1969363 be responsible for this (comment 16 has great str)?

It looks like after the FolderPopulation refactor landed in 143, folder discovery bails on the first child error (for example when a Windows MAX_PATH limit is hit) instead of continuing, so other folders or siblings disappear from the tree.

nsMsgDBFolder::AddSubfolder doesn’t append to mSubFolders when CreateFolderAndCache returns NS_MSG_FOLDER_EXISTS, even though it returns a valid folder.

Do you think switching PopulateFolderHierarchy to “log & continue” on errors, and always appending when we have a valid folder pointer, would restore the 142 behavior?

Flags: needinfo?(edicharry)

I don't have a Windows system on which to reproduce that specific failure, but it definitely seems plausible. I'll see if I can come up with a way to reproduce this on Mac or Linux and in any case try and come up with a fix.

Flags: needinfo?(edicharry)
Assignee: nobody → edicharry
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

To reproduce this on MacOS 26 in TB 147, I needed at least 11 levels of nesting, each with a name length of at least 256 characters. Although this did not cause a complete abort, and top-level folders further down in the hierarchy did not disappear. Another complicating factor for reproducing this is that we hash the end of individual folder names to limit them to about 50 characters, so just creating long individual paths for this won't work. You need to create deeply nested structures.

Keywords: regressionwindow-wanted
Regressed by: 1969363
Keywords: checkin-needed-tb
Target Milestone: --- → 147 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/555018ea7c24
Continue traversal of a parent folder when a sub-hierarchy fails. r=tobyp

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED
See Also: → 1998118
See Also: → 2015590
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: