247552 - When upgrading to 0.7, problems not finding the 0.6 profile on OS X

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Scott MacGregor]

I thought I had fixed all of the problems with OS X and the new profile location
(Bug #246285) but I see that I have missed something. It seems the new format
change for salted directories is interferring with Thunderbird's ability to find
the 0.6 profile:

Most Mac Users are having the experience summarized here.

http://forums.mozillazine.org/viewtopic.php?p=584753#584753

"My old 0.6 profile was in
"Home"\Library\Thunderbird\Profiles\default\xxxxxxxx.slt (xxx is the salted {or
hashed} profile name which I HATE... looks like 0.7 will avoid salting, yeah...
but I digress)

0.7 wanted to create a new profile in
"Home"\Library\Thunderbird\Profiles\default.s1m (with no *.slt subdirectory),
and did not detect or migrate any previous profile info.

In "Home"\Library\Thunderbird\ I stumbled on a Profiles.ini file that had the
following section (and yes it is an INI file on a Mac) containing:

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

Open the Profiles.ini file with TextEdit or similar and edit the Path line to
point to your old Profile as in:

Path=Profiles/default/xxxxxxxx.slt (or whatever your was)

Now a launch of 0.7 uses the 0.6 profile. "



"

Comment 1

[Scott MacGregor]

I might consider re-releasing the Mac bits if I can get a fix for this and the
non ascii profile path bug. 

Comment 2

[Scott MacGregor]

removing the dependency. This bug is for an OS X specific problem and has
nothing to do with intl windows profiles.

Comment 3

[Scott MacGregor]

This is a very strange bug. 

Any debug or optimize build that I build by hand, properly finds the old profile
and uses it. 

Any release generated build shows the problem and the new profile code fails to
get a profile from the NS registry lookup stuff.

Comment 4

[Scott MacGregor]

It turns out this was a problem with the release build. It was not generating a
 correct compreg.dat that goes inside the Thunderbird.app package. As a result
the migrator class wasn't even registered so we never tried to look for a profile. 

This explains why any build I tried myself to debug the issue always worked. 

Leaf and I have fixed the release machine that makes the 0.8 nightlies. So this
will be fixed in the 0.8 nightlies starting on 06/26. 

We're in the process of re-spinning 0.7 (0.7.1) to address this. 

Comment 5

[Scott MacGregor]

FYI, this problem is fixed on the 0.8 nightly build machine.

We also corrected the issue for 0.7.1.

Comment 6

[Jason Gerard DeRose]

(In reply to comment #5)
> FYI, this problem is fixed on the 0.8 nightly build machine.
> 
> We also corrected the issue for 0.7.1.
> 
> 

However, I'm still having the same problem with 0.7.1 under GNU/Linux.  I'm
using the Debian package from:

http://www.jwsdot.com/debian/index.html

(It's a pre-release package from the Debian mozilla-thunderbird maintainer.)

When upgrading from the Debian Sid 0.6-3 package to the Debian 0.7.1-0.0.asac1
package mentioned above, 0.7.1 does *not* detect my 0.6 profile.

Comment 7

[André Lehmann]

I have the same problem on WIndows XP. I have tried with both 0.7.1 & 0.7.2, and
never suceeded to retreive the 0.6 profile. Removing 0.7.x and reinstalling 0.6
solves each time the problem.

Comment 8

[Asaf Romano (gone)]

"Mac OS X" can't rum on PC hardware :-)


marking as a mac bug....

Comment 9

[Benjamin Smedberg]

The mac bug is fixed, and was a specialized problem with build packaging. If you
still experience problems on Windows or Linux builds, it belongs in a different bug.

NOTE: mozilla.org traditionally does not handle bug report which are
Debian-specific. I suspect that the binary package is not forcing a
re-registration by touching an .autoreg file in the install directory.