Closed Bug 1542025 Opened 2 years ago Closed 1 year ago

Thunderbird 67, 68 and newer betas does not use existing profile

Categories

(Thunderbird :: Installer, defect)

defect
Not set
major

Tracking

(thunderbird_esr6870+ fixed)

RESOLVED FIXED
Thunderbird 71.0
Tracking Status
thunderbird_esr68 70+ fixed

People

(Reporter: emoore, Unassigned)

References

()

Details

(Whiteboard: [Fixed by bug 1583129 and bug 1587067])

I have both Thunderbird version 52.9.1 and 60.6.1 installed under Windows 10 Home version 1809, sharing the same profile. I installed the latest beta (67.0b1) using custom setup and it did not find my existing profile. Instead it created a new profile and ran the new account wizard.

I re-tested using the older versions of Thunderbird and they did not have a problem finding and using the original profile. I then edited the shortcut for the beta to specify the original profiles location using command line arguments. It found it and used it. I exited the beta, edited the shortcut to remove the arguments specifying the profiles location and ran the beta again. It didn't use the original profile, and ran the new account wizard again. It is using the same profile (C:\Users\Eric\AppData\Roaming\Thunderbird\Profiles\ak29d4a7.default-beta) that the beta created the first time I ran it.

It appears that the Thunderbird 67 beta is using a dedicated profile per https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installation and https://www.mozilla.org/en-US/firefox/dedicated-profiles/

I checked the release notes. There was no mention of this. There should have been.

A typical user doesn't know or care about a change in the Mozilla toolkit, they expect Thunderbrid to continue using the same profile. Many install beta or earlybird builds and expect them to just work. They don't have the mindset of treating the other channels as something separate and/or inherently risky. They just want the latest bug fix and/or enhancements. You can argue whether this is right or wrong, but its a very common attitude.

That is why I didn't set the bug report type to "enhancement". Thunderbird users are used to every channel using the same profile. The Firefox explanation for dedicated profiles is "This will make Firefox more stable when switching between installations on the same computer". Most Thunderbird users don't switch between installations on the same computer after installing another channel. We also don't have an equivalent of Firefox Sync.

I expected Thunderbird to transparently workaround this change in a external library since I was able to get Thunderbird to use the original profile by using command line arguments, and it knows where the profiles.ini file is. It doesn't seem to be a implementation issue, it seems more like a question of policy.

If its decided that its too risky to disable dedicated profiles (due to future changes in the Mozilla toolkit) something like a warning message with a option to clone the default profile as a channel specific profile should have been provided. However, whats direction is decided, the current approach (do nothing) is wrong.

My profiles.ini file contains:

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=Profiles/w0p7q3aa.default
Default=1

[Profile1]
Name=Test
IsRelative=1
Path=Profiles/ufg82m3r.Test

[Profile2]
Name=default-beta
IsRelative=1
Path=Profiles/ak29d4a7.default-beta

Hmm, yes, I should have added something to the release notes. I wasn't aware that existing profiles aren't found. It's more about not being able to go back once a newer version has been run on the profile, see bug 1535116.

Magnus, you've followed the "profile by install" more closely. Why aren't existing profiles found and updated?

Flags: needinfo?(mkmelin+mozilla)

Wow, I had never seen this before since I always start non-ESR versions with -p, and TB 67 will see the existing profiles if started with -p. But starting it without -p it does not use the last profile set as default but instead creates a new profile "default-beta". I wonder why we haven't had more complaints from beta users so far.

I'm adding something to the TB 67 release notes right now.

Matt, Wayne, has this been an issue on the support forums?

Flags: needinfo?(vseerror)
Flags: needinfo?(unicorn.consulting)

I'm under the impression it will reuse the existing default profile under a "normal" upgrade scenario. But when using a beta or nightly it would not treat that as the same install.

From https://hg.mozilla.org/mozilla-central/rev/58babf220962, I think if the install dir is the same as it always was, you'll get same default profile you used to have. If it's something else, it will be treated as a different installation and set up a new profile.

Could someone test this out?

Hmm, if this is the case, it does bring up issues with 32 bit and 64 bit installations and a possible switch between them...

Flags: needinfo?(mkmelin+mozilla)

I wonder how are Firefox beta users handling this? And what does their documentation say?

I haven't seen reports in SUMO or discourse, and this wasn't flagged in our smoketesting of 67.0b1 - possibly because testers use "-p" (as I did).

I was generally aware of these issues, but haven't been using beta on a daily basis for several months and so I will leave assessment, and developing advice to give to our beta users to others more experienced. But I imagine this will be a pain in the butt for me and many others.

Flags: needinfo?(vseerror) → needinfo?(ryanvm)

I'm not seeing "-beta" profile thing with 67.0b1 build2 but I did see this "-beta" profile creation behavior when I tested the extracted .ZIP version Firefox 67.0b8 the other day. I din't know if the issue is related but that's, oddly, where I observed it.

Well did the paths from which you ran differ?

I would recommend actually using the supported installer version for installing beta builds too. Zip installs is not really a supported thing and some stuff will not work as intended due to the installer not running.

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

Well did the paths from which you ran differ?

I would recommend actually using the supported installer version for installing beta builds too. Zip installs is not really a supported thing and some stuff will not work as intended due to the installer not running.

Let me clarify more. I did not unzip over my existing install. GOD NO! I simply extracted the .ZIP contents to my desktop and ran the .EXE from the extracted folder. I always use the normal installer when upgrading.

I'm always using the TB release version with my working profile and test the beta and Daily versions in dedicated profiles. Since I'm not using desktop shortcuts to open the different versions, launching any version will open the Thunderbird profile manager in which I manually select the adequate profile.

So in my installation Daily 67 or Thunderbird 67 did not create new profiles since they continued to use the same dedicated profiles which had already been used by the previous betas and Daily.
But I noticed that now when I start Thunderbird 67 or Daily 68, the profile manager opens and automatically selects the "dedicated" profile. I also noticed that a new file named installs.ini has been created in the Thunderbird folder.
My installs.ini file has the following contents:

[66974FBEB6E816F]
Default=Profiles/c77hyfne.Daily
Locked=1

[31115F10F8B0D331]
Default=Profiles/t1j8it28.Nex67build1
Locked=1

[BBEFDE3DB4B32610]
Default=Profiles/pctry1zh.TestTB67b
Locked=1

[66974FBEB6E816F4]
Default=Profiles/c77hyfne.Daily
Locked=1

Flags: needinfo?(ryanvm) → needinfo?(dtownsend)

I see the same as Eckard in Comment 8 using Thunderbird release from Ubuntu and Thunderbird, a Beta and Daily testing on Ubuntu 18.04.2 LTS.

My ~./thunderbird folder also has the new installs.ini file with these entries:

[25D81D83F19E669]
Default=boq4v51g.daily
Locked=1

[2486E3961890B2DA]
Default=7r790knz.beta
Locked=1

[25D81D83F19E6694]
Default=boq4v51g.daily
Locked=1

I was able to select the profile for my Thunderbird 60.6.1 in the Profile Manager and open TB 67.0b1 with it. Confirmed by checking Help > Troubleshooting Information > about:profiles that version 67.0b1 was using my version 60.6.1 profile.

My installs.ini now has these entries:

[25D81D83F19E669]
Default=boq4v51g.daily
Locked=1

[2486E3961890B2DA]
Default=bofr8b4v.release
Locked=1

[25D81D83F19E6694]
Default=boq4v51g.daily
Locked=1

I'll try some testing with versions 52.9.1 and 60.6.1 using the same profile, and 67.0b1 in my test user account and see what happens.

I installed TB 52.9.1.

Opened it from a terminal with the -p profile switch.
Created a test profile.
Made sure "Use the selected profile without asking at startup" was disabled.
Clicked Start Thunderbird.
Disabled updating.
Created an email account and downloaded email.
Quit TB 52.9.1.

Started the Ubuntu supplied TB 60.6.1 with the test profile using the profile manager.
Quit TB 60.6.1.

Installed TB 67.0b1.
Started it with the test profile using the profile manager without a problem.
After starting this version the installs.ini file was created with this entry.

[314E342D6501D514]
Default=9rakyj2k.test
Locked=1

I had not seen or heard anything about this, until I saw a post in TB planning alluding to us actively preventing downgrades yesterday. This is a very significant change from a user perspective and a retrograde step that appears to have little to offer the user. Or am I missing something. Without sync, forcing profile changes will be a disaster for Thunderbird.

I am not sure what we do with the next major regression that gets in the wild. But that MAPI thing would have been much much worse if folk could not just install the previous version. Every release comes with something that requires a "downgrade" for some users until things settle down and the next point release comes out with a fix.

Flags: needinfo?(unicorn.consulting)

(In reply to Jorg K (GMT+2) from comment #1)

Hmm, yes, I should have added something to the release notes. I wasn't aware that existing profiles aren't found. It's more about not being able to go back once a newer version has been run on the profile, see bug 1535116.

Magnus, you've followed the "profile by install" more closely. Why aren't existing profiles found and updated?

The existing profiles should be found and the profile that was previously the default should be assigned to one of the Thunderbird installs. The logic for doing so is definitely not perfect since without user interaction (which we decided would just confuse the majority of users) we can't be sure which install they'd prefer to get the old default.

There are a few edge cases but the rough logic is that when an install has just been upgraded to support dedicated profiles it looks at the previous default profile and if it was last used by this install then it selects it for its default for the future. Otherwise it creates a new profile for itself to use. The profile manager should still list all the profiles and allow selecting a different default though it's worth noting that with the downgrade protection on selecting the same default for two installs is likely to not work out well.

Flags: needinfo?(dtownsend)
Duplicate of this bug: 1545182
Severity: normal → major

I confirm that I CAN use my default profile with 68.0a1 x64 after updating, if my shortcut that starts TB has the -p switch (as Walt said above), by then selecting the DEFAULT profile from its DB. Shouldn't TB be coded so that, if the command line has no switches, it assumes that DEFAULT profile? Starting with the Profile Manager is an annoyance.

The "use profile without asking" box is then checked, and if I then remove the -p from the shortcut, TB x64 now starts normally with that DEFAULT profile. Usable, but not intuitive for a non-techie user.

Summary: Thunderbird 67 beta does not use existing profile → Thunderbird 67, 68 and newer betas does not use existing profile
See Also: → 1566490

I just tried to upgrade from 60.0.8 32-bit to 68.0 64-bit and ran into this problem. I uninstalled the 32-bit version and then installed the 64-bit version. Upon startup, it gave me the new account wizard and it created a new profile called: {profile name}.default-release

I uninstalled the 64-bit version, installed the 68.0 32-bit version, and it immediately was using the old, original profile {old pofile name}.default correctly.

So people switching to the newly released 64-bit build will all run into this problem.

Support forum has shown an issue that seems linked to this bug.
Old computer - Windows 7 OS - was running version 68 with no issues.
New computer - Windows 10 OS - had version 68 newly installed. Using Help Support page, copy pasted the Roaming/'Thunderbird' folder to new computer.
This was done correctly, but they could not get Thunderbird to run the old profile.
There was a difference in content comparing the 'profile.ini' file on old computer and on new computer. There was also a 'installs.ini' file on new computer. The new computer using same version as old computer had created a new profile using .default release. This '.default release' profile was apparently 'Locked', but still the user's standard profile would not open and the line 'StartWithLastProfile=1' was not in the 'profiles.ini' file.
This caused much confusion and an exasperated user. It resulted in editing the 'profiles.ini' file to remove any mention of the '
.default release' profile to get all working again. Fortunately, this user was competant and not daunted by accessing the profile folders etc.

I'm not sure whether this person had installed the 32bit on one machine and 64bit on another and ran into similar issue as described by Jon Grossart in previous comment.

But I fear there could be future questions in Support of this type.

General users do not use -P nor do they use the 'Profile Manager' to swap between profiles when they only have and use one profile.
Many users seem find it hard enough following the instructions on how to copy paste the Roaming/'Thunderbird' folder to another computer and launching the 'Profile Manager' is sometimes beyond their capabilities. Unhelpfully, Thunderbird does not auto create a shortcut icon called eg: 'TB -profile Manager' when installing the program. The concept of 'Profile Manager' is alien to most users.

Can we rethink what is trying to be achieved and the way it is being done and not make it more complicated for the average user.

with regard to previous comment - I should mention that the 'installs.ini' file also had to be altered as it contained the '*.default release' profile.

Another report - not same user as previously mentioned....
Windows OS 64bit
User previously using win32 version 60.7 had auto update that failed - resulted in no shortcut icon and discovered there was no thunderbird.exe file.
All profile data was fully intact.
User decided to manually download win64 version 68 from https://www.thunderbird.net/en-US/thunderbird/all/

Program installed and created a new profile name *.default-release
Thunderbird starts and uses the new profile asking user to create mail accounts which they do as prompted and now have a few new emails in the new pop Inbox. Thunderbird does not start/locate and use user's original profile which is located in the same 'Profiles' folder as the new *.default-release. This was not the expected behaviour.

User has pop mail accounts, emails in Local Folders and address books in other profile etc etc.
User is much confused as to how they are supposed to get their old profile working and why Thunderbird is not auto locating profiles.
User has only used one Profile and only one version of Thunderbird at any one time.

So issue mentioned by Jon Grossart appears to be starting to pop up in Support Forums.

re comment 19. advised user to redownload 'win32' version 68, after initial glitch of not wanting to work due to 'other versions', Thunderbird finally started working and immediately picked up the original profile.
Many people are now using computers with OS 64bit and upon seeing Thunderbird download options, they may choose to download win64 option.
If they have used win32 in the past then they are going to have issues.

What is preventing newly downloaded win64 version from not locating original profile ?
Can this be fixed for next update?

I don't think that will change. It's due to the profile-per-install feature. AFAIK, things will work as expected on an upgrade, but if you install another version on the side, then it will go to a new profile by default. It is keyed on the install location.

The workaround is to start with "thunderbird.exe -P" to bring up the profile manager and select the original profile. (Yes, hard to find if you don't know about it.)

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

The workaround is to start with "thunderbird.exe -P" to bring up the profile manager and select the original profile. (Yes, hard to find if you don't know about it.)

Yes it is difficult. I had difficulty with this and I do not consider myself a noob. Perhaps we can prioritise inclusion of the profile manager access into the user interface where it should have been for a decade.

We had an add-on which demonstrates that is is possible, but I do not see it getting any more updates
https://addons.thunderbird.net/en-US/thunderbird/addon/profileswitcher/

(In reply to Matt from comment #22)

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

The workaround is to start with "thunderbird.exe -P" to bring up the profile manager and select the original profile. (Yes, hard to find if you don't know about it.)

Yes it is difficult. I had difficulty with this and I do not consider myself a noob. Perhaps we can prioritise inclusion of the profile manager access into the user interface where it should have been for a decade.

There is access to the profile manager from Troubleshooting information with the about:profiles link at the bottom of the Application Basics heading.

This page helps you to manage your profiles.

Users can create new profiles using the "Create a New Profile" button.

I'm not sure when it first appeared in Firefox and was picked up by Thunderbird.

(In reply to WaltS48 [:walts48] from comment #23)

This page helps you to manage your profiles.

Users can create new profiles using the "Create a New Profile" button.

I'm not sure when it first appeared in Firefox and was picked up by Thunderbird.

That is good to know! I certainly had missing it's appearance. It would appear I was not alone or we would not have all these instructions about Thunderbird -P

Now how to craft this box of lemons into a user support article that makes sense to those that will be list after click Help > Troubleshooting information.

I suppose I also need to raise a bug for the incorrect button "Launch profile in a new browser"

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

I don't think that will change. It's due to the profile-per-install feature. AFAIK, things will work as expected on an upgrade, but if you install another version on the side, then it will go to a new profile by default. It is keyed on the install location.

The workaround is to start with "thunderbird.exe -P" to bring up the profile manager and select the original profile. (Yes, hard to find if you don't know about it.)

So does that make this bug a WONTFIX?

I'd say the important thing is we need an user friendly process for users who encounter this. Whether it is resolved through this bug or some new bug or process. Seems like the in product profile manager would be one good possibility.

Can the contents of the 32-bit profile just be copied into the 64-bit newly created profile? Or does that mess something up.

compatibility.ini is the only immediate one I see that might cause trouble since it references the 32-bit install info.

Perhaps there needs to be a "migrate profile" or something feature. I imagine this will be a problem for people that move to a new machine from having a constantly updated install (which just works) to a new install as well (which will be looking for the newer naming convention).

Of course, -p can mitigate that.

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

I'd say the important thing is we need an user friendly process for users who encounter this. Whether it is resolved through this bug or some new bug or process. Seems like the in product profile manager would be one good possibility.

Given we have access to the existing About:profiles having a top level menu item in the help or tools menu pointing to About:profiles might be a good user friendly way to cope with all of this. With an easy to locate item that gives the user access to a screen with a "Make default" button is about as easy as we could make it. Other than not implementing it in the first place.

Undoubtedly offering simple access to profile manager will see some bugs uncovered as it is rarely used outside of developers and those that use the command line.

It would seem there are cases where the updated 'profiles.ini' file is lacking the information to use last opened profile which should not be a new '.default release' profile name.
When upgrading, using the current profile set as default should be the default action in upgrade.

I notice:
Current default profile is not always used when updating as it should be by default.
In addition: The following line is either missing altogether or has the value as 0.
StartWithLastProfile=1
Should this line be included to ensure 'profiles.ini' knows what to do?

I've seen some weirdness over the past few weeks.
eg: 'about: profiles' says Thunderbird is using default old profile. But 'profiles.ini' file does not agree requiring 'profiles.ini' to be edited.

We are in the process of upgrading to TB68. At the moment every single upgraded pc needed a manual editing of the profiles.ini as TB68 created a new empty default-release profile.

Out environment looks like this:

  • Win7 Pro 64bit (domain joined)
  • Roaming profiles
  • wpkg (our software packaging solution) does the following:
    • remove 32bit tb-60.8.0
    • install 64bit tb-68.1

I think that tb-68 should check for existing profiles and offer an upgrade on first launch by an user. This process then should create a copy of the old profile for the new one. After two weeks (or 14 successfull launches) it should ask to remove the legacy profile.

See Also: 1566490
Duplicate of this bug: 1566490

If after upgrading or downgrading the user has to repeatedly rechoose the one and only profile that contains all their data, what is the purpose of creating extra profiles that are never going to be used ?
Anyone can create an extra profile and copy their data if they really need to use an extra profile but the vast majority would only do that if a profile became corrupted.
At the moment there is a lot of Support Forum questions about not able to locate profiles and in some cases old profiles are missing vital data and rendered useless.
Is this some Firefox copying of code which may be useful in Firefox but has no place in Thunderbird.
It just does not sound like something specifically developed for Thunderbird because it would never be required.
There is something not logical about this entire change.
It is causing alot of concerns with users needing the likes of myself and others to help fix messed up files, accounts etc and some people are reporting complete loss of data.
I now have users requesting editing Thunderbird folders and files to completely remove all auto added profiles, so what is the problem likely to be if they are removed?

What is the real reason for forcing new profiles that are then never used.?
It cannot have anything to do with compatibility as the first thing anyone does is not use the new profile and the advise is to select the old profile.
I would like to see this stopped and as quickly as possible.

Downgrading is not supported.
Data (like database schemas) can need to change on upgrade, and if you then downgrade, you can get the profile into a very bad state.

Hey guys, I wanted to chime in here about a recent system migration I did of a user PC from Win XP 32-bit to Win 10 x64 1903. User was running TB 52.9.1 x86. I did a profile copy from the old PC to the new and upon starting TB 68.1 x64 for the 1st time, I didn't get any profile errors or other issues yet I was almost certain I would hit this bug.

I use Windows 10
I was using 60.8.0 then downloaded and installed version 69.0b3.
then removed it and installed version 68 after a few days....
Then removed it and installed 60.8.0 from main download webpage, then auto updated to 60.9.0
Finally, a week later, manually installed version 68 and allowed auto upgrade to 68.1.0
I do not have any additional profiles, none were ever created and non deleted.
I only have one profile which is default and always used, plus a copy of it - just in case.

I had no idea about all this extra profiles until Supprt Forum started with all kinds of issues.

Updating from 32 to 64 bit causes a change of install location program file Vs Program Files (x86) so is not an "upgrade" it is a new install. That is the issue, and I think a technical solution is what is required.

Asking 10 million folks to manually reset their profile folders because we have finally got off our collective and released a 64 bit version. Firefox did not have an issue like this because they had already done the 64bit migration.

Dedicated profiles uses the installation directory to determine which profile to use This is taken from https://hg.mozilla.org/mozilla-central/file/58babf220962945b5ed8b4af5309d81eb8376571/toolkit/profile/nsToolkitProfileService.cpp

So we need a technical solution to migrate profiles to 64 bit versions without this user facing rubbish to continue. Perhaps we need to equate "program files" and "Program Files (x86)" as the same location for the purposes profile selection.

(In reply to Matt from comment #36)

(Edited) Updating from 32 to 64 bit causes a change of install location "Program Files" vs. "Program Files (x86)", so it is not an "upgrade", it is a new install. That is the issue, and I think a technical solution is what is required.

Can we confirm that this is the issue? Has anyone carried out this test on a machine that really only had one 32bit installation with one profile to start with. We developers have a bazillion profiles and versions, so it would be hard to test.

Also I heard that an upgrade install that switches from 32 to 64 bit would install the 64bit binary into the x86 location. Ugly, but working.

Flags: needinfo?(rob)

I tried it myself and did this:

  • renamed C:\Users\jorgk\AppData\Roaming\Thunderbird to C:\Users\jorgk\AppData\Roaming\Thunderbird-good to hide existing profiles
  • installed TB 60.9 32bit into C:\Program Files (x86)\Mozilla Thunderbird, ran it and created a new profile
  • ran TB 68 64bit which was previously installed, and yes, it didn't recognise the old profile.
  • removed C:\Users\jorgk\AppData\Roaming\Thunderbird to start again with a new profile
  • changed app.update.channel to trigger an update to 68, but it wasn't offered, so I got stuck :-(

For the record, I tried the following values: cdntest, beta, release-cdntest, esr-cdntest, but no update was offered.

Did you change thunderbird/defaults/pref/channel-prefs.js?

Flags: needinfo?(rob)

No. I edited app.update.channel in the config editor.

I don't think editing the pref in the config editor does anything. You need to edit the file.

Yes. So repeating comment 38:

I tried it myself and did this:

  1. renamed C:\Users\jorgk\AppData\Roaming\Thunderbird to C:\Users\jorgk\AppData\Roaming\Thunderbird-good to hide existing profiles
  2. installed TB 60.9 32bit into C:\Program Files (x86)\Mozilla Thunderbird, ran it and created a new profile
  3. ran TB 68 64bit which was previously installed, and yes, it didn't recognise the old profile.
  4. removed C:\Users\jorgk\AppData\Roaming\Thunderbird to start 60.9 again with a new profile. Created a feed account in the new profile. Closed TB.
  5. edited C:\Program Files (x86)\Mozilla Thunderbird\defaults\pref\channel-prefs.js to use release-cdntest.
  6. Restarted TB. I was upgraded to TB 68.1 32bit. After the upgrade, I went on with the profile create in step 4.

So in summary: I got upgraded from 60.x 32bit to 68.1 32bit and the profile was reused.

So where does the 64bit upgrade come in?

Flags: needinfo?(rob)

From IRC:
20:17:16 - rjl: the 64 bit thing we think happened because it was the default windows download on the website. balrog is not set up to make the switch and never was
20:20:51 - jorgk: I see. So no automatic cross-grade from 32 to 64

Flags: needinfo?(rob)
Depends on: 1583129

Can the internals of a profile just be copied into a new profile (accounting for editing compatability.ini)?

This comment is a heads up on reality - eg: what is going on with users based on Support Forum questions and personal experience.

The point we need to understand is regardless of what version users use, including going back to previous because of any reason like addons do not work, users will want to use the profile that has all their data. They expect Thunderbird to automatically find and use it. If Thunderbird starts and shows nothing then there is an initial panic after which with some guidance they will point it to use the original profile.
Some users have just given up and downgraded in order to see their data again.

It is unreasonable to expect users to do anything else. They just want to use the profile that has their data and they do not expect nor often have the ability or confidence to rumage around inside the various files editing and fixing them.

What might be reasonably easy for you or me is way beyond the abilities of most people who just want to read and write emails.

It is a fact that people are downgrading and upgrading and they are always using the same profile.
In some cases they are deleting any other auto created profiles because they deem them as unwanted and confusing/cluttering up their 'Profiles' folder.

At the moment, some users have no issue and TB finds profile - this was my experience, others simply need to access 'about:profile' and choose the original profile as default, but some are trying to use their old profile and discovering profile cannot be located because files corrupted eg: 'profiles.ini' and 'prefs.js' or their 'profile name' folder suddenly containing mbox files, unusual *.sbd files eg: (gmp.sbd. Mail.sbd etc) .msf files (calendar-data.msf) or contents completely deleted. Some users are prompted with computer needs restarting to complete the install, but this action fails and they are stuck in a loop. This always results in some loss of profile data. In my experience I have never been asked to reboot a computer when installing or updating Thunderbird.

The upgrading is causing more issues than just not seeing a profile and needing to point to it.

Manually deleting existing version of Thunderbird 32bit and manually downloading and installing version eg: 68.1.0 32bit does not cause any issue and in my experience does not create additional profiles such as .default release profile name. So if uninstalling and going back to previous version, will this not cause an issue ?

All various issues that have arisen have only occured with the auto update, usually from 60.9.0 win 32bit to 68.1.0 32bit or 60.9.0 win 32bit to 68.1.0 64bit.

Questions:

  1. When an auto upgrade from 60.9.0 to 68.1.0 occurs and a new profile called .default release is created, should the 'profiles.ini' still say to open and use the current default profile as previously used? Why is this failing?
  2. If a .default release profile is created should it already contain a copy of the original default profile?
  3. If a manual installation of 68 or 68.1.0 occurs why is no .default release profile is created?
  4. Why are some people upon auto update being asked to do a restart of computer which results in corruption of files?

Please help us to understand what is going on and what should be occuring. so we can help users experiencing a wide variety of problems and get valuable information to those helping to sort out bugs.

(In reply to Anje from comment #45)

Questions:

  1. When an auto upgrade from 60.9.0 to 68.1.0 occurs and a new profile called .default release is created, should the 'profiles.ini' still say to open and use the current default profile as previously used? Why is this failing?

After upgrading Thunderbird should use the same profile as it used to. If people have multiple installs of Thunderbird, perhaps something gets messed up? Whether to use a new profile or not is based on the installation path. (Profile per install!) So different installation path, different profile. Upgrades would reuse the same installation path, and all should be fine.

  1. If a .default release profile is created should it already contain a copy of the original default profile?

It would not.

  1. If a manual installation of 68 or 68.1.0 occurs why is no .default release profile is created?

That depends on where you installed it. If you installed it over the same installation path, you'd be kept on the same profile.

  1. Why are some people upon auto update being asked to do a restart of computer which results in corruption of files?

I doubt this is related to Thunderbird. Probably bad coincidence.

Hi Magnus.
re :After upgrading Thunderbird should use the same profile as it used to. If people have multiple installs of Thunderbird, perhaps something gets messed up? Whether to use a new profile or not is based on the installation path. (Profile per install!) So different installation path, different profile. Upgrades would reuse the same installation path, and all should be fine.

In Forum, the Users do not have multiple installs. A simple update is occuring from 60.9.0 to 68.1.0 and profile is in the default location.

re :That depends on where you installed it. If you installed it over the same installation path, you'd be kept on the same profile.

So you are actually saying the same profile can and does work perfectly ok on any version of Thunderbird, if the person does not use auto update, but instead uninstalls old version first and then installs the latest to ensure only one version is installed and being used. That fact speaks volumes. There is no compatibilty issue.

It's just some quirk that Firefox are using for a browser.
In that case, I'm of the opinion that the latest idea of using firefox code in Thunderbird is causing a lot of issues and problems and they are totally unnecessary as it does not matter what profile you use on any version of thunderbird.

Sometimes, it is a valid point to recognise when something is not working as expected. It should be removed and end all this waste of time and upset as it serves no purpose. Firefox and Thunderbird are not the same animal.

I've spent dozens of hours helping to fix profiles and currently I'm not always successful as the damage is sometimes too great.
It does not help when those using 68.1.0 get fed up and go back to 60.9.0 simply because it works and they are waiting for you to allow them to update without any issues.

Hi Anje,

I understand your frustration. We developers are just as frustrated.

We decided to stick with the Mozilla platform for now, and that platform implemented a "profile by install" policy to protect from downgrades damaging profile data or being incompatible with a profile from a later version. In its core that is a good idea. We had profile upgrades in Thunderbird where a downgrade later would cause trouble.

We realise that "Firefox and Thunderbird are not the same animal". Firefox profiles are pretty much "throw away"; where users use Firefox sync they even get their bookmarks in a new profile for free. The case is much different for Thunderbird where multiple gigabytes of precious e-mail data is store in the profile.

That said, a straight update from a 32bit TB 60.x to a 32bit TB 68.x, as I tried in comment #42, is without problems. Also a transition from a 64bit TB 60.x to a 64bit TB 68.x is without problems. I manually upgraded a friend last week and there was no problem at all.

I think the issue arises when the "bit-ness" of the install changes, and we're working in bug 1583129 to mitigate this.

Magnus tried to answer all your questions. Personally I don't have much experience with this issue as - being a developer - run all installation with -allow-downgrade since all my profiles are touched by various versions of TB. I understand that the .default-release profiles are created if the new install decides not to use an existing profile, for whichever reason.

Finally, it can happen on Windows that upgrading TB will require a restart. That's the case if some DLL was locked during the installation. Of course that should cause any profile corruption.

Duplicate of this bug: 1584475
Depends on: 1587067

Fixed by bug 1583129 and bug 1587067. Fix will be backported to TB 68.2.0 ESR.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 71.0

Reports of updating from 68.1.1 to 68.1.2 who are losing profiles.

I am talking about people already using win32 version and updating using a win32 version.
New unwanted profiles are being auto created, which makes the user believe their profile is either lost or deleted.
It is forcing the user to use eg: Profile Manager to force Thunderbird to use correct profile.
Any Thunderbird installation should use the one and only profile that contains all the data.

lost profiles etc is not just an issue between updating from win32 to win64.

Manual install into a different location? If automatic update to the same location didn't work, you'd have 750.000 people complaining.

Yep, it was an automatic update that failed. win32 68.1.1 to win32 68.1.2
User then discovered two thunderbirds in Program(x86) one for each version.
User deleted both and then downloaded and installed 68.1.2
It created a new profile, so user thought they had lost a profile.
They were savvy enough to use Profile Manager to locate correct profile, but had no idea why initial update failed nor why a new install created a new profile or why it did not locate the one and only profile in use.

I'm providing information that I see on Support Forum that could be relevant. It could also be a fluke.
But better to know or be aware about it than ignore.
The point is an auto update failed to find profile, removing and reinstalling 68.1.2 also failed to find profile and produced new profiles.
Showing symptoms as discussed in this bug.

No idea where you got the '750.000 people complaining' figure.
I'm absolutely certain Thunderbird has relevant bugs that do not always show themseleves to 750.000 people who all instantly complain. It still does not mean there isn't a bug.

Thanks for the information. Any install into a different location will not use the existing profile. "two thunderbirds in Program(x86)" must mean that the install directories were different. Mozilla's new "profile by install" « feature » will create a new profile in this case, but you can always select the old one in about:profiles on the profile manager.

According to current stats (I heard on the grapevine), we have 750.000 users on TB 68.x, so all those would have complained had the upgrade from 68.1.1 to 68.1.2 gone wrong.

Duplicate of this bug: 1582351
Whiteboard: [Fixed by bug 1583129 and bug 1587067]

TB 68.2.1 just arrived in Ubuntu LTS (18.04) and it did exactly this for me on startup. AFAIK the installation path would be the same (/usr/bin/thunderbird), but I’m guessing this was caused by trying v. 68 in another folder a while back. I had prepared by making sure I had a separate 60.9.1 on hand before the upgrade, but how is the average end-user supposed to know what is going on? Many people would assume TB had just deleted their e-mail and use something else. They would not know or care what a bug tracker was.

It would be good to know how it’s supposed to work and what the implications are, e.g. are v. 68 profiles really incompatible with v. 60? If the new version is creating a new per-install version of profiles, shouldn’t it make a copy of the default profile? Why isn’t there something like “What you need to know about upgrading” on the main webpage? If you end up having to edit the 2 .ini files, it would be useful to know what/where the installs actually are. “Install30C149437553F650” does not tell me much. The profile manager also doesn’t tell you what version a profile is associated with, so “avoiding corruption” becomes a bit theoretical.

An ExQuilla user trouble-shooted together with me for quite a while, and he eventually found that this bug was the cause. He wrote, in part:

I finally found the issue caused because profile seems corrupted and even plugins disabled, TB68 cannot read it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1542025 [= this bug here]
I've created new fresh profile and setup ExQuilla from first, then it works!
Thank you for taking time for me...

You need to log in before you can comment on or make changes to this bug.