This may be one of those bugs which only happens once during upgrade process.

I upgraded from 93? series to 102.1.2 finally (the upgrade button appears in the last day or so).

There are a few things that bothered me during upgrade and so I am listing them here.
One of them, the failure to correctly carry over the mail storage directory was most disturbing.
I have specified the Mail storage directory NOT under the profile directory because , for various reasons, I need to store a lot of e-mails for the last dozen years or so.

Factors that bothered me after the upgrade and restart.

• There is a server that does not support encrypted connection.
  But I let the encrypted negotiation (I think that TB tried it first and then went on to connect unencrypted). It used to work without a hitch.
  With 102.1.2, TB almost got hung after it says, one of the servers did not support TLS conenction? (sorry I failed to capture the screen).
  As soon as TB came back to life, I changed the setting of the server to try plain text connection only.
• The Mail directory is carried over from the old setting incorrectly.
  See that attached. Note the strange prefix of "C:\Users\ci". There is an incorrect logic somewhere in the installer. This is VERY BAD obviously. I got greeted with almost empty mail directorys, which made sweat run down my spine. Because the failure in upgrading wiped out my whole mail directory (!?).
• There is another issue. I realized the incorrect setting of mail storage directory eventually after a couple of restarting TB.
  But each time I tried to shutdown TB, I got the warning from TB stating something like
  "There is a problem with spam handling setting for ishikawa@yk.rim.or.jp. Check before saving the profile."
  Well, at least during one of the trials, I never intended to save the profile.
  AND this dialog could not be eliminated. No matter if I checked cancel, it came back repeatedly.

Hmm...

So I changed my setting to save junk file to a junk folder, but probably it is incorrect.
It probably pointed to a non-existing folder name (maybe prefixed by the wrong c:\users\ci prefix as in the original folder.?"
Sorry I already fixed the issue and do not know what the incorrectly folder name was.

So I have a bitter feeling that the my account setting is probably messed up one way or the other, which I will find out over the next week or so when something does not work as it used to do. :-(

Bad.

I can not fetch my e-mail from my servers like I did for the last 17 years or so.
The installer this time sucks, to be frank.

Still trouble shooting. I am afraid TB is too difficult for ordnary user when a trouble like this happens.
Not enough warning/error messages in the error console. Even a timeout message for connection would help, but nothing.
Only if I change the port of pop3 server, I get socket error...
Hmm. Can it be if the mail server at the local ISP is not responding?

Well, it seems that it is related to the use of POPfile proxy for spam filtering.

There is a similar report who could not use POPfile once that user is on a newer TB version.
https://support.mozilla.org/ja/questions/1369790#answer-1510892

So now, this part of the protocol is handled by pop3client.jsm (?).

Hmm...

Working e-mail is essential.
So I had to remove POPfile proxy from TB setup. Now it works.
But this is sub-optimal.

There is a similar report who could not use POPfile once that user is on a newer TB version.
https://support.mozilla.org/ja/questions/1369790#answer-1510892

I will investigate POPFile interaction on a separate PC using a local mail server.

Thanks for the great details.
Please file a seperate bug for each issue, which will help get them resolved more quickly.

Will do.
Right now, my theory about POPFile not working may be due to tightened up certificate handling. My ISP's pop3 server uses SSL/TLS connection. But this essentially means that local POPFile proxy serves as a middleman. It has the address 127.0.0.1 and TB talks to 127.0.0.1 but it does not have its own certificate. So I am not sure what happens then. Maybe the older TB had looser check in such a situation.
Also, new developers may find it hard to debug POPFile interaction because POPFile has not been updated for a long time. It got stuck 1.1.3.
I have a 1.1.3 zip file and at the office, I do use POPfile, and I have been using POPfile under Windows at home. Except, I just found out that I do not have POPfile installed in my linux environment where I intend to test.
So I will be moving slowly.: there are a few issues that crop up on this Saturday and I need to handle them either by changing the config file of my local server, or installing an old package.

There are a few issues.
I filed a couple more bugzilla entries.

1. Mail storage directory is not carried over to the upgraded installation. (Let us use this bugzilla entry)

2. POPFile spam classification proxy does not work any more(?)
   Bug 1786172

3. There seems to be quite lengthy hung period where the TB does not
   respond when the TB has an incorrect server setup (immediately after
   the update and maybe after an incorrect new specification for server,
   etc.)
   Bug 1786173

Mail storage directory is not carried over

It's using the same profile as earlier. Everything should be available as it was earlier.

Had you changed the storage directory so something non-standard?

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

Mail storage directory is not carried over

It's using the same profile as earlier. Everything should be available as it was earlier.

Had you changed the storage directory so something non-standard?

This was my mail directory where all the mail folders are stored.

O:\new-Doc-and-Settings\Application Data\Thunderbird\Profiles\3n8dufys.default\Mail\mail.yk.rim.or.jp

And it is the one I am using now.

Somehow upgrade process changed it into

C:\Users\ci\O:\new-Doc-and-Settings\Application Data\Thunderbird\Profiles\3n8dufys.default\Mail\mail.yk.rim.or.jp

In the original screen capture attachment.)
https://bug1786120.bmoattachments.org/attachment.cgi?id=9290739
Prepending "C:\Users\ci" seems a clear bug. (CI is my local user account name).

Well, it is not the default place.
BUT, there is a clearly marked text box where we can change the directory. So, I think this is not a big deal. (Attachment to this post.)

And, for that matter, the past upgrade process honored this for a quite some time. It has been like this for at least a few years, I think.
I have never had this problem.

Something has changed in the latest installer (updater).

EDIT: I fixed the incorrectly prepended string. Upper vs Lower
Incorrect: c:\Users\CI
correct: C:\Users\ci
ci is the local account name which I use.

To be honest, I am not even sure if the update/installer picked up the correct profile in its first attempt at all.
Thus ensued my utter confusion about mail directory and server setup.

(In reply to ISHIKAWA, Chiaki from comment #10)

To be honest, I am not even sure if the update/installer picked up the correct profile in its first attempt at all.

We've had other reports of this, and as you know it is highly disruptive and stressful. So if you can put some time to reproducing or diagnosing this, it would be a big win for us.

There may be multiple reasons for this to happen. In some cases it seems to be related to the user putting profiles in a non-standard location. (I can't cite an example right now)

(In reply to Wayne Mery (:wsmwk) from comment #11)

(In reply to ISHIKAWA, Chiaki from comment #10)

To be honest, I am not even sure if the update/installer picked up the correct profile in its first attempt at all.

We've had other reports of this, and as you know it is highly disruptive and stressful. So if you can put some time to reproducing or diagnosing this, it would be a big win for us.

There may be multiple reasons for this to happen. In some cases it seems to be related to the user putting profiles in a non-standard location. (I can't cite an example right now)

I see. I can certainly attest this is very disruptive and stressful.
I had to spend the better part of Sunday for this before obtaining (seemingly) working TB, and I am not sure if I am using some
incorrect values for the various configuration parameters. Hmm..

I will definitely try to figure out if the problem can be related to

• USE of link or junction to place TB profile under non-standard place.
  I am certainly not placing thunderbird profile in the default place.
  I think I am using a link (or junction) to place my local profile on non-C (non-boot) drive to save space in the smallish boot drive.

• Multiple profiles
  I have a few profiles switched for testing purposes. (<- this really can't be, I think.)

• Non-standard installation place, not C: drive:
  In the old days, maybe several years ago, I installed TB in L:\program files(x86) drive as opposed to C: drive.
  There may have been some crufts left over in L:\ drive that may have confused TB updater.
  (But I suspect that the registry file under Windows10 may have started afresh anyway since I had to re-install Windows10 due to a screwed up driver early this year. Re-installation had not happened for a long time. I carried over old installation by upgrading from windows 7 PRO (64-bit) to Windows 10 Pro (64-bit) bit.

• 32-bit to 64-bit transition
  Aha, I have switched to TB 64-bit rather lately. So It is possible some crufts left over from 32-bit installation may have confused updater.

These are the things that may confuse updater off the top of my head.

The most likely thing of relevance is the placement of profile and using links or junctions.

It would be interesting to know the values for mail.server.server<NN>.directory-rel and mail.server.server<NN>.directory prefs for the affected server. If you have backups for the data, check what it was before the upgrade as well. Did you even manually adjust those values, not through UI?

I noticed bug 1786218 while investigating this. I don't really see how it would have caused it though, unless elsewhere other code would find that path to be inconsistent and then try to recreate the pref or something like this... so perhaps a small possibility of that.

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

The most likely thing of relevance is the placement of profile and using links or junctions.

It would be interesting to know the values for mail.server.server<NN>.directory-rel and mail.server.server<NN>.directory prefs for the affected server. If you have backups for the data, check what it was before the upgrade as well. Did you even manually adjust those values, not through UI?

Thank you, Magnus for investigating this very disturbing issue.
I just found out to my ... I don't know the right English word ..., that indeed TB screwed up OTHER paths used for folder.
Suddenly, I got an error saying that a copy of e-mail sent cannot be stored into Sent folder
due to network error or file access error.
It says

• I should re-try, which failed again, but the message shown then is incorrect, I think.
  It says, there is not enough disk space to store newly downloaded message. Try again after removing old messages, empty trash folder, and/or
  compact folder(s).
  I think it refers to the same root cause. Non-existing path ???

, or store it manually in a folder in the Local Folders/sent-<user account name>

Well, I checked the Local Folders/Sent folder path (not the sent-<user account name>, mind you), and found to my surprise it points to a directory in C: and probably not as I wanted. (Remember, I want to store possibly unbounded amount of messages ELSEWHERE, not on boot device.)
Not sure if it was like this before. Beside, note "Unsent Messages". It is supposed to be "Sent" folder. Ugh...
mailbox:///C:/Users/ci/AppData/Users/ci/AppData/Roaming/Thunderbird/Profiles/uh2scuat.default/Mail/Local Folders/Unsent Messages

My original Sent folder is inside the mail storage directory which I rectified using the GUI yesterday.
Well, NO, now I realize that I have a broken folder :-(
I often send e-mails from my home PC using my own ISP using "From address: of my office e-mail address".
Some will argue I should use VPN to connect to my office server, but directly using my home ISP's server to send an e-mail that is coming from my office e-mail address worked just fine.
I now realized that the mails originating from my office e-mail address I sent from my home PC's TB using my own ISP would end up in the
folder that has the name of the office e-mail address. And there used to be a Sent folder beneath it.
Sent folder is not there any more.
That is why sending the e-mail failed. There was NO Sent folder there any more. So that means I lost the e-mails having my office e-mail From address, sent from my home PC Hmm... What is going on?

Did you even manually adjust those values, not through UI?
Never.
I always used UI to change the Mail storage directory.

mail.server.server<NN>.directory-rel and mail.server.server<NN>.directory prefs fo

Are they in prefs.js or somewhere?

Yes, in prefs.js

I saw some similar error messages when I manually changed hostname in prefs.js to something non-working. That may be the cause of the other symptoms. No idea how the hostname would have become wrong though.

For your folders, I'd assume Sent, and others are somewhere, but may not be trivial to locate if it's spread up over a few locations.

In the old prefs.js saved some time ago before it got broken during upgrade.
These are the relevant mail.server.server<NN>.directory and mail.server.server<NN>.directory-ref.

user_pref("mail.server.server3.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\mail.yk.rim.or.jp");
user_pref("mail.server.server3.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/mail.yk.rim.or.jp");

Rel does not look very nice with "O:/" in the middle of pref value, but please recall I did set it up using TB GUI.
And so the old TB code handled it just fine.
Now the updater somehow misinterpreted it?

The following is the ones in prefs.js USED CURRENTLY AFTER I FIXED the location from TB GUI.
Ouch. Why do I have the feeling that I would be bitten again?

user_pref("mail.server.server3.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\mail.yk.rim.or.jp");
user_pref("mail.server.server3.directory-rel", "[ProfD]../../../../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/mail.yk.rim.or.jp");

Now, note the different number of "../" in the |directory-rel| string, and again the appearance of "O:/" in the middle.
I have a feeling that the different number of "../" from the previous one is already a suspect.

For your folders, I'd assume Sent, and others are somewhere, but may not be trivial to locate if it's spread up over a few locations.
Somewhere...
I think I found it in a different directory in a different server account.
This may be due to the fact that I found a typo in the dummy host name for the office e-mail address that I use on my home PC.
TB insists that I create an account with that e-mail address so that I can select THAT e-mail address in From: address.
Unless it is defined thusly, the e-mail address could not be chosen from a pre-defined selection if I want to rewrite the From address field.
I found an undesirable spelling yesterday while I was checking the profile after the mail directory was missing.
I fixed that. That may probably caused TB to miss the original location of the Sent folder.
(Yeah, now that I think about it, I think I can explain the missing Sent folder thing.)

However, the discrepancy of the number of "../" used by the older TB version and 102.1.2 for |.diretory-rel| pref IS A BIG CONCERTN.

Hope this helps.

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

. No idea how the hostname would have become wrong though.
That was me correcting an unwanted spelling mistake for a dummy host (not used for real communication at all) during the debugging of the original issue of incorrect Mail storage directory.

That mutated hostname was used for the office e-mail address account.
I did not send out the e-mail using that e-mail address over the weekend.

But I did on Monday afternoon and that problem surfaced. But I think I can handle that without much ado.

The different number of "../" in the directory-rel string between 102.1.2 and the earlier version I used is the major concern now.

BTW, there is a program called "Everthing". It searches the entire file system for files that matches a pattern and is quite useful
in a situation like this.

I could find the misplaced "/Sent" file in about a few minutes of experimentation.
Or for that matter, I could find the relevant prefs.js quickly.
(There were so many due to my old installation from XP days, and some others for testing purposes created over the years and backed up online.)

The search can be done using regular expression (or without such fancy feature).
"Everything" is one of the few apps on Windows I would recommend to developers.

https://www.voidtools.com/

I am still trying to see what happened, but my tentative conclusion is that
for mail accounts,
The # of "../" in |directory-rel| is 5 in the old pref.js (that worked with older TB 9x.y) and
it is 8 in the current pref.js (after the change via GUI).
The different number IS A SUSPECT in the detection of inconsistency and incorrect fix (that prefixed "C:\users\ci" to the directory
where the mail is stored.)

I can't say for sure what happened with news account. I don't use often anymore.

I am trying to recover the misplaced messages (sent from a non-default From address) into the correct directory and such right now.
I did find a very strange directory setup over the years (12+ years). These may have confused the TB.
But do note TB 9x.y and earlier did not have problem with this setup over the years.
This is the first time I have such a serious and disturbing problem during update.

It is only three days since the update corrupted my mail setup and I only found today that during update to 102.1.2, not only the main mail account, and another pop3 mail account had incorrect mail storage directory, but another imap account I created also had incorrect mail storage setting.
So all the mail accounts I have had the same problem of being prefixed with "C:\Users\ci" before "O:\new-Doc-and-Settings...".
And after the fix via GUI, the number of "../" prefix in |directory-rel| has become 8 whereas it was 5 for all mail accounts.

I think I will monitor and investigate more and produce a report.
But due to the local mess of directory setup, it may not be an easy read.
I am creating the report so that I can keep my sanity in the midst of directory maze which I created over the years,
and to recover whatever misplaced messages in the wrong place to correct place carefully right now.

Here is what I observed for the last 8 days to figure out how the directory settings were messed up by TB.
There seems to be quite complicated directory setting on my part.
This **may have confused TB, but again older versions of TB did not have any issues at all. **

** This is long. **

Please recall the previous updater/TB versions handled the
particular directory setup for a few years at least without an issue.

On my PC.
C:\Users\ci\AppData\Roaming\thunderbird
is a junction/link to
l:\ci-appdata\thunderbird

Here is my recap.
I have found out that TB 102.1.2 updater or TB 102.1.2 itself
"corrected" directories for accounts in an incorrect manner.

Also, to my horror, I did have a very strange directory setup for
"Local Folder". I am not sure if that confused TB 102.1.2. I suspect
it did not.

I have three mail accounts (two pop3 and one imap) and one news
account set up.
I have used one pop3 account.
The other pop3 account was created to ease the input of different
"From" address when I send an e-mail using my own ISP.
By creating an account with that e-mail address, the address shows up
in the selection. Otherwise, I have to type it in manually.
That account points to a non-existing server.
The imap account was created for the same reason. I simply make this
dummy account point to non-existing server, too.

I have reported the problem of incorrect mail storage directory of the
first, main pop3 account I use daily.
Then I noticed ** the other pop3 account (dummy account) also had the
mail storage directory incorrectly specified.** Thus, when I sent an
e-mail using that "From" address, TB could not find the correct
directory to save, and offered to save it under
"Local Folder/Save-<that-e-mail-address>" folder.
I fixed it last week.

Initially, the reason for TB's not discovering the correct directory
was that I somehow corrected the misspelling of the server name, but
this rendered the older mapping invalid.

But during the revering the fix for misspelling manually last week, I
noticed TB obviously tried to set the mail directory again with
INCORRECT "C:/Users/ci/" prefix for the mail storage directory of
accounts. There is a mechanism of "automatic (mis-)correction when
certain "discrepancy" of |directory| and |directory-rel| is noticed".
The different number of "../" in the mail storage directory accepted
by the older TB 9x.y and TB 102.1.2 suggests that there is something
wrong in the detection and the way directory is normalized.

Last week, I noticed that **the dummy ISP account also had the mail
storage directory with the incorrect "C:\Users\ci". ** It has been fixed
manually through GUI.

All the changes I made to the directory setting have been through GUI,
mind you, for all these years.

I finally took the time to compare all the |directory-rel| in the old
saved prefs.js and the current somewhat incorrect one that I have been
using since Monday the week before.

Then I realized news account setting also suffered from this incorrect fixing by TB. I have not
bothered to correct it yet.

First the excerpt from the OLD Profile that used to work with 9x.y TB.
Current partially incorrect Profile that is now used with 102.1.2

Hhere is the output of "grep directory prefs.js"
But I have not corrected the discrepancies I found last time.

From OLD prefs.js:

grep directory old-prefs.js:
user_pref("ldap_2.servers.default.uri", "moz-abldapdirectory://default.mab");
user_pref("mail.server.server1.directory", "L:\\Users\\ci\\AppData\\Roaming\\Thunderbird\\Profiles\\uh2scuat.default\\Mail\\Local Folders");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../Users/ci/AppData/Roaming/Thunderbird/Profiles/uh2scuat.default/Mail/Local Folders");
user_pref("mail.server.server2.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\xxx.example.org");
user_pref("mail.server.server2.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/xxx.example.org");
user_pref("mail.server.server3.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\mail.yk.rim.or.jp");
user_pref("mail.server.server3.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/mail.yk.rim.or.jp");
user_pref("mail.server.server4.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\News\\news.mozilla.org");
user_pref("mail.server.server4.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/News/news.mozilla.org");
user_pref("mail.server.server5.directory", "C:\\Users\\ci\\AppData\\Roaming\\Thunderbird\\Profiles\\uh2scuat.default\\Mail\\smart mailboxes");
puser_pref("mail.server.server5.directory-rel", "[ProfD]Mail/smart mailboxes");
user_pref("mail.server.server7.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\News\\news.mozilla.com");
user_pref("mail.server.server7.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/News/news.mozilla.com");
user_pref("mail.server.server8.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\ImapMail\\mail.example.com");
user_pref("mail.server.server8.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/ImapMail/mail.example.com");

grep directory NEW prefs.js:

user_pref("ldap_2.servers.default.uri", "moz-abldapdirectory://default.mab");
user_pref("mail.server.server1.directory", "L:\\Users\\ci\\AppData\\Roaming\\Thunderbird\\Profiles\\uh2scuat.default\\Mail\\Local Folders");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../Users/ci/AppData/Roaming/Thunderbird/Profiles/uh2scuat.default/Mail/Local Folders");
user_pref("mail.server.server2.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\xxx.example.org");
user_pref("mail.server.server2.directory-rel", "[ProfD]../../../../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/xxx.example.org");
user_pref("mail.server.server3.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\Mail\\mail.yk.rim.or.jp");
user_pref("mail.server.server3.directory-rel", "[ProfD]../../../../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/Mail/mail.yk.rim.or.jp");
user_pref("mail.server.server4.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\News\\news.mozilla.org");
user_pref("mail.server.server4.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/News/news.mozilla.org");
user_pref("mail.server.server5.directory", "C:\\Users\\ci\\AppData\\Roaming\\Thunderbird\\Profiles\\uh2scuat.default\\Mail\\smart mailboxes");
user_pref("mail.server.server5.directory-rel", "[ProfD]Mail/smart mailboxes");
user_pref("mail.server.server7.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\News\\news.mozilla.com");
user_pref("mail.server.server7.directory-rel", "[ProfD]../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/News/news.mozilla.com");
user_pref("mail.server.server8.directory", "O:\\new-Doc-and-Settings\\Application Data\\Thunderbird\\Profiles\\3n8dufys.default\\ImapMail\\mail.example.com");
user_pref("mail.server.server8.directory-rel", "[ProfD]../../../../../../../../O:/new-Doc-and-Settings/Application Data/Thunderbird/Profiles/3n8dufys.default/ImapMail/mail.example.com");

Long Details only meant for developers.

|Normalize()| mentioned in previous comment does not "normalize" in
the same manner in 9x.y TB and TB 102.1.2 obviously. That is the
problem. Or for that matter, its detection of "inconsistency" is not
the same with those of older versions of TB.

I think TB noticed the inconsistency due to this and tried to "fix"
the directory setup in prefs.js, but actually turned it into an
invalid one.

Smoking Gun:

To recap, I noticed a different number of "../" in the prefix of
|directory-rel| pref in the saved old pref.js that used to work with
TB 9x.y, and the latest prefs.js that was produced after the upate to
102.1.2.

There were some broken directory settings and I fixed them by
resetting the value via GUI.

I checked the difference between the old saved prefs.js and the new
partically incorrect prefs.js that I am using with TB since Monday
previous week.

But I need to explain a few things.
After taking a look at the value of |directory| and |directoy-rel|
I realized I have a really messy directory setup.
This is the result of using this over 12+ years switching from XP, 7
and 10 via different hardware, I think.

But somehow TB of various previous versions handled this without
complaining and breaking the operation at all.

uh2scuat.default is a VERY OLD default prof I had.

When I moved some mail directories/folders out of under then current profile I am
using to save space of the drive where the profile resides,
I seem to have kept using the OLD directories/folders for certain
folders such as "Local Folders" and "smart mailboxes" (what is this? I
don't use unified folder and probably this is it?).

Other directories/folders are under the current profile's Mail
directory.

The current profile I am using reside in the following.
O:\new-Doc-and-Settings\Application Data\Thunderbird\Profiles\3n8dufys.default

I realized that the two different directories make the analysis below quite confusing.

========================================
OLD pref.js analysis:

Two folders are used under the directory of the VERY OLD profile, uh2scuat.default,

They appear as follows in the saved prefs.js before the update woes :
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"
C:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\smart mailboxes"

Due to the link/join,
C:\users\ci\appdata\roaming\thunderbird points to
L:\ci-appdata\thunderbird

There are two directory locations which popped up in my new and old prefs.js.
They point to different places but Local Folders are now pointing at them.
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"
L:\ci-appdata\thunderbird\profiles\uh2scuat.defaut\mail\local folders

Oh, I am not sure why we have two references L: and C:. It could be due to the
join/link I have used or have I manually specified them so?
You can't underestimate the ingenuity of fools, I mean users.

I found out that
c:\users\ci\appdata\roaming\thunderbird is actually a link
(join?) to
L:\ci-appdata\thunderbird.
So the second line above is equivalent to
L:\ci-appdata\Thunderbird\Profiles\uh2scuat.default\Mail\smart mailboxes"

But then why do we have the follwoing directory?
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"

But it seems we have the following directory,
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default

I have to check if the two folders is actually the same. Hmmm.
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"
C:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders",

The latter actually being
L:\ci-appdata\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders.

It seems I have separete directories, this is something I should rectify. I have no idea how this happened.
It is interesting to see how 102.1.2 updater handled this mess.
(I will come back to this later. It seems it simply carried it over to
the new pref.js but with different number of "../" prefix in |directory-rel|.)

Dir #    mail          under old     # of "../" old | # of "../"s new
                       uh2scuat.default   
1        local folder  YES           4                   4
2        Yes           NO            5                   8
3        Yes/POP3      NO            5                   8
4        News          NO            5                   5
5        smart mailbox YES           0 No drive spec     0 No drive spec
6        n/a           n/a           n/a                 n/a
7        News          NO            5                   5
8        Imap          NO            5                   8

NEW pref.js analysis:

Two folders are used under the directory of the VERY OLD profile, uh2scuat.default,
They appear as follows in the saved prefs.js before the update woes :
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"
C:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\smart mailboxes"

Oh, I am not sure why we have two references L: and C:. It could be due to the
join/link I have used or have I manually specified them so?
You can't underestimate the ingenuity of fools, I mean users.

But it seems we have the following directory,
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default

So I have to check if the two folders is actually the same. Hmmm.
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"
C:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"

It seems I do have separete different directories, this is something I should
rectify. I have no idea how this happened.
It is interesting to see how 102.1.2 updater handled this mess.
(I hope I will come back to this later.)

With this background, let us see what is |directory-rel| and
|directory| prefs in the old saved pref.js and corrected pref.js I use
now. (The current one still have problems.)

Note the difference of numbers of "../" in the prefix of
|directory-rel| prefs.

Now I realize that server1 that uses a directory location in the really old uh2cuat.default directory setting
has four (4) "../"s in the prefix of ProfD.

But server2, server 3 had eight (8) "../"s in the prefix of ProfD.
However, server4, the news directory, had ** five (5) "../"s ** in the
prefix of ProfD.

Server 5 that uses really old uh2cuat.default directory for smart
mailboxes had NO "../" prefix.

There is no entry for server 6.

Server 7 for a news account that uses a directory under 3n8dufys.default profile (the current profile)
had five (5) "../" in the prefix of ProfD.

Server 8 for an imap account has eight (8) "../"s in the prefix of ProfD.

It looks like a mess, but there must be a reasonably logical
explanation according the old code base.

cf. Discovery: On top of the incorrect fix, I must have incorrectly
specified the directory for "Local Folders" in a strange place without
knowing it before.

TODO: fixing "Local Folders" directory

Old "Local Folders" is in the following.
L:\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders"

Local Folders, however, after TB 101.1.2 udpate,
"Local Folders" point at

C:\Users\ci\AppData\Users\ci\AppData\Roaming\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders

The following is where it should be.
L:\ci-appdata\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders
(I have found out this old directory contains the old "Local Folders"
circa 2012).

I wished I would consolidate the content of "Local Folders" in the
following directory and let "Local Folders" point at this directory.
L:\ci-appdata\Thunderbird\Profiles\uh2scuat.default\Mail\Local Folders

This is what I did.

It doesn't of course help figure out the bug, but I suspect you just have to go into the file system and move everything into whatever consolidated place you with to have it in.

Re fake servers: it is better to just set up another identity, instead of an account.

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

It doesn't of course help figure out the bug, but I suspect you just have to go into the file system and move everything into whatever consolidated place you with to have it in.

Re fake servers: it is better to just set up another identity, instead of an account.

I see. Come to think of it, it makes sense. For the next testing session, I will do that.
Actually, under Linux, I have created a different account for testing purposes.
I have not really tried to create different identity for testing purposes under windows. It is not quite comfortable to switch between two users under windows performance-wise.

Re the original problem.

I think whatever "normalization" of relative directory path string is all about, the difference of
"../" prefix in the old and the new paths used in the prefs variable |directory-rel| suggests there is a semantical difference
between the pre 102 TB and 102 TB.
I think that is where we need to focus our attention.

the new pref.js but with different number of "../" prefix in |directory-rel|.)

Dir #    mail          under old     # of "../" old | # of "../"s new
                       uh2scuat.default   
1        local folder  YES           4                   4
2        Yes           NO            5                   8
3        Yes/POP3      NO            5                   8
4        News          NO            5                   5
5        smart mailbox YES           0 No drive spec     0 No drive spec
6        n/a           n/a           n/a                 n/a
7        News          NO            5                   5
8        Imap          NO            5                   8