Steps to reproduce:

Operating system: Windows 7 Pro (64-bit)

Years ago, the C: drive on my wife's computer was getting full, so I moved her Thunderbird profile to the D: drive. That is, I:
Shut down Thunderbird.
Created directory D:\AppData\Roaming
Moved C:\Users\Karen\AppData\Roaming\Mozilla\ to D:\AppData\Roaming\Mozilla
Created a symlink at C:\Users\Karen\AppData\Mozilla to point to the new location on D:
Restarted Thunderbird.
I did NOT change any of the server settings. The local directories could be accessed by the same paths as previously thru the symlink. This all worked fine for several years.

C:\Users\Karen\AppData\Roaming>dir Mo*
Volume in drive C is WIN7PRO
Volume Serial Number is 3089-C58F

Directory of C:\Users\Karen\AppData\Roaming

08/24/2013 06:06 PM <SYMLINKD> Mozilla [D:\AppData\Roaming\Mozilla]
0 File(s) 0 bytes
1 Dir(s) 69,764,272,128 bytes free

Note that the direct path to D:\AppData\Roaming\Mozilla is two steps shorter than the path from C: through the symlink.

The prefs.js file contained “directory-rel” entries like this:

user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../../../../C:/Documents and Settings/Karen/Application Data/Mozilla/Profiles/Karen/vflnbcv4.slt/Mail/pop.compuserve.com");
user_pref("mail.server.server2.directory-rel", "[ProfD]../../../../../../../C:/Documents and Settings/Karen/Application Data/Mozilla/Profiles/Karen/vflnbcv4.slt/Mail/Local Folders");
user_pref("mail.server.server3.directory-rel", "[ProfD]../../../../../../../C:/Documents and Settings/Karen/Application Data/Mozilla/Profiles/Karen/vflnbcv4.slt/Mail/pop.earthlink.net");

Recently, her Thunderbird was upgraded from 91.13.1 (20220908191136) to 102.4.1 (20221024184826). Immediately after the upgrade her “Local Folders” and POP3 email accounts were inaccessible. In the “Folders” tree view in Thunderbird there were root entries for those, but they had no folder children under them and could not be expanded.

There was no error message until while troubleshooting I opened the account settings. Then an error message was displayed: 'The Local Directory path “C:\Users\C:\Documents and Settings\Karen\Application Data\Mozilla\Profiles\Karen\vflnbcv4.slt\Mail\pop.compuserve.com” is invalid. Please pick a different directory.'

In reading the directory-rel entries from profs.js, the newer version of Thunderbird somehow miss-interpreted the string “[ProfD]../../../../../../../” as “C:\Users\” instead of a null string,

I note a suspicious coincidence: The direct path to the local folders from D: is TWO steps shorter than the old path from C: thru the symlink, and Thunderbird has prepended TWO bogus steps to the path.

Re-entering the unmanged Local Directory paths in the server settings and restarting fixed the problem.

Steps to reproduce:
Requires a computer with Windows 7 Pro Service Pack 1 (64-bit), and two hard drive partitions, C: and D:
Install an older version of Thunderbird (91.13 or older)
Set up POP3 email account(s) to download mail to the local directory and delete from the server.
Set up some Local Folders and move some emails into them.
Shut down Thunderbird.
Move the AppData\Mozilla folder to the D: drive, setting up a symlink in it's place on the C: drive (see above). The direct path to the new location from D: should be at least two steps shorter than the old path thru the symlink.
Restart Thunderbird and verify everything is working. No changes are made to server settings or preferences, since the Moziilla folder is accessed by the same path as before, but now thru the symlink.
Upgrade Thunderbird to version 102.4.1 or later.

Actual results:

On restart after the upgrade, the Local Folders and POP3 email accounts are inaccessible. Their Local Directory paths have been corrupted.

Expected results:

On restart after the upgrade, the Local Folders and POP3 email accounts should have been accessible. Their Local Directory paths should have been valid.

Bug 1786120 is same/similar. Most upgraded to 102 already, so whatever's going on, it's not been wide spread.

from bug 1786120.
Very similar. I am glad to see a reproduced case.
Due to similar reasons, I created a link to
L:\ci-appdata from
c:\users\ci\AppData\Roaming\thunderbird

And got bitten.

For those already bitten, they may have figured out the issue.

But someone somewhere might decide to create a symlink to save space on default device.
That person may not see the problem with newer versions (?) in the future, that is.

Oh, I see, maybe the new pop3 JS code is to blame.
So once whatever strange path canonicalization happens with JS code and is OK today,
maybe the problem won't happen unless the problematic code is rewritten to be correct, I guess.