Updating server setting in Thunderbird reverts with restart
I'm trying to update the server settings for an email address in Thunderbird, but it reverts to the old settings when Thunderbird restarts.
I go to the account settings for the email address of interest. I then update the Server Name or the User name (they both do the same thing). This then produces a pop-up that says "Restart is required to apply the server name or username change." Click OK to restart and when Thunderbird has restarted the Server Name/User Name has reverted back to the old setting.
A similar thing happens if I try and make the matching changes to the outgoing SMTP settings. They appear to change until Thunderbird restarts at which point the old settings have been restored.
I needed to make this change to two PC's. One PC (a windows 11 PC) worked fine. The other (a windows 10 PC) consistently fails. The affected PC is using the latest Thunderbird ver 115.5.1.
What am I missing here? Why can't we change the Server settings?
선택된 해결법
I fixed it.
To get around the Schrodinger file I created a new temporary parent folder. Copied everything from the 03e9mwi8.default folder into this new folder. Thankfully this copy excluded the existing/non-existent prefs.js file. Then in the new folder copied prefs-27.js to prefs.js. Finally moved the 03e9mwi8.default folder out of the way and moved the new folder into this name. Started Thunderbird and everything then worked fine. I was able to update the server/user name details as normal.
Bit of a mission but we got there.
문맥에 따라 이 답변을 읽어주세요 👍 0모든 댓글 (4)
The changes are written to disk when Thunderbird closed and are stored in a file prefs.js. I guess we are looking for a reason the file might not be updated for you out of the millions of Thunderbird users.
Some common reasons are;
- The computer has it's power lost before the files are written to disk. (ie just turned off)
- The profile files are stored somewhere other than the local hard disk. (NAS storage, cloud synced locations and streaming backup included here)
- The profile folder files are being scanned by the antivirus product and the relevant file is locked by the scanner as the time the write attempt is made. (This often results in prefs(1).js through some huge numerical number of files being written on each shut down and then ignored on startup.)
Thanks for the reply here. It has pointed me in what looks like the right direction but I've still got a challenge.
File manager told me that prefs.js did not exist. I did have prefs-1.js through prefs-27.js. prefs-27.js was dated only a few months ago and a quick read of its contents and it appears to match the existing setup. So simple fix me thinks. Shutdown Thunderbird, Delete prefs-1.js through prefs-26.js, Copy prefs-27.js to prefs.js and restart Thunderbird. Should be simple enough.
That was until I got a errors trying to overwrite the existing (non-existent) prefs.js file. It looks like I have a Schrodingers file here that both exists and doesn't exist at the same time.
Even using the cmd window with admin permissions and I get this: C:\Users\username\AppData\Roaming\Thunderbird\Profiles\03e9mwi8.default>dir prefs.js
Directory of C:\Users\username\AppData\Roaming\Thunderbird\Profiles\03e9mwi8.default
File Not Found
C:\Users\username\AppData\Roaming\Thunderbird\Profiles\03e9mwi8.default>copy prefs-27.js prefs.js Overwrite prefs.js? (Yes/No/All): yes Access is denied.
0 file(s) copied.
I'm not sure of my next step here, but it does look we need to sort this file out first before we can make the server config change we need.
Suggestions appreciated.
선택된 해결법
I fixed it.
To get around the Schrodinger file I created a new temporary parent folder. Copied everything from the 03e9mwi8.default folder into this new folder. Thankfully this copy excluded the existing/non-existent prefs.js file. Then in the new folder copied prefs-27.js to prefs.js. Finally moved the 03e9mwi8.default folder out of the way and moved the new folder into this name. Started Thunderbird and everything then worked fine. I was able to update the server/user name details as normal.
Bit of a mission but we got there.
You still need to address the cause of the issue that creates these numbered files, or nothing will really change.