| Summary: | Thunderbird upgrade creates new directories [account-1] in the place of existing account ones | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frank Griffin <ftg> |
| Component: | RPM Packages | Assignee: | Nicolas Salguero <nicolas.salguero> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | fri |
| Version: | Cauldron | Keywords: | FOR_ERRATA9 |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | thunderbird-102.10.1 | CVE: | |
| Status comment: | |||
| Attachments: | As requested, hope it helps | ||
" if you rename the new [account directories] to the old names and repopulate them from the old directories, all is well " Thank you for this succint work-around, tedious though it must be. Can you find any log of the upgrade, perhaps /root/drakx/report.bug ? If so, and it is the correct date, if you can find the bit that relates to Thunderbird, please poste that. Thunderbird has just been version-updated again (May 11) new version 102.11.0, and this may stop the problem. If it did, it would only be effective from on-line upgrades, not necessarily those done with the Classic ISO which would normally have an older version. Assigning this to ns80, our current Thunderbird packager, in case the problem arises from the way the upgrade is done. Please advise Frank on evidence that might help. Keywords:
(none) =>
FOR_ERRATA9 Created attachment 13834 [details]
As requested, hope it helps
I hold off entering this in errata but for now let FOR_ERRATA9 stand as reminder to check. I have not seen another noting on this, and I run TB on m9 myself in production since beta2 release and that have survived all TB updates. I suppose that also an upgrade from reasonably updated mga8 will have no problems. CC:
(none) =>
fri |
This was first noticed on May 9 2023 on a system which updates cauldron several times a day, and rebooted several times that day. TB, which restarted at reboot, came up with a new account prompt instead of using the existing 3 accounts already defined. Probing into this, I found that my existing {profile}/Mail subdirectories were intact and contained all of the mails they were supposed to. However, TB had created new account subdirectories with the existing names suffixed by "-1", e. g. "myserver.com" had added a new subdirectory of "myserver-1.com". These new subdirectories had default empty subfolders. I tried manually deleting these and restarting TB, but they were just recreated again. Then I tried manually altering all of the references to the "-1" subdirectories in prefs.js to eliminate "-1" while TB was down and restarted TB. This had no effect. Finally, on a hunch, I renamed the existing myserver.com directories to myserver-x.com, deleted the entire contents of the myserver-1.com directory, renamed myserver-1.com to myserver.com, and copied the entire contents of the myserver-x.com directory to the new myserver.com. I also ensured that prefs.js was still referencing myserver.com, and started TB. THAT worked. This worked for both a POP3 server account and a "Local Folders" (non-server-related) account under Mail. TB did not find a previous IMAP account under ImapMail, and again created new empty "-1" subdirectories under ImapMail. Again, deleting these just got them recreated. Again, renaming the old ones to myserver-x.com, renameing the new one to myserver.com, and copying all the existing contents to the new myserver.com "worked", but I had to go through defining the IMAP account again at which point the copies of the existing mailfiles were recognized. All I can guess is that there are some attributes of the existing subdirectories which disqualify them from use by the new TB, forcing TB to create new ones. Because if you rename the new ones to the old names and repopulate them from the old directories, all is well. I've been using TB for years, and I've never seen anything like this. Any ideas or explanations welcome.