383051 - Profiles not detected in migrator for apps that use profiles.ini instead of registry

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/2007060302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Making the IRC story short:

I:
{{
My TB registry.dat:
No "Profiles" in there,
only "Users", "Common", "Version Registry", "Private Arenas".

TB registry.dat dated 29/01/07 << profiles.ini dated 03/06/07.
}}

Mark:
{{
The migrators assume registry.dat,
and newer versions of apps don't use that, they use profiles.ini :-(
}}

Comment 1

[Mark Banner (:standard8)]

Affects all OS, I've just confirmed it on Linux.

Comment 2

[Mark Banner (:standard8)]

Attachment: The fix

This fixes the problem with Thunderbird profiles (note SeaMonkey migration was never affected by this bug as previous versions all use registry.dat or whatever its called on the appropriate bug).

This changes the Thunderbird migrator, so that it checks for profiles.ini first, if it doesn't find that it will fallback to the appropriate registry file, because we're using semi-generic functions, I've had to change some of the SeaMonkey profile migrator as well, but there shouldn't be any functional change for that. I've based the reading of profiles.ini on nsToolkitProfileService.cpp.

Comment 3

[[e-mail]]

Comment on attachment 267071 [details] [diff] [review]
The fix

Note: I have no Thunderbird profiles so this is more of an sr than a review.

>+  nsresult GetProfileDataFromProfilesIni(const  char* dataDir,
Nit: doubled space

>+  // There is no nsILocalFile clone :-(
Yes there is. It's inherited from nsIFile. Note: without reading your code a bit more carefully I can't tell whether you can get away with an nsIFile or whether you'll have to QI the clone back to an nsILocalFile again.

>+  unsigned int c = 0;
>+  for (c = 0; PR_TRUE; ++c) {
Nit: for (PRUint32 c = 0; ; ++c) {

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> Created an attachment (id=267071) [details]
> The fix
> 
> This changes the Thunderbird migrator, so that it checks for profiles.ini
> first, if it doesn't find that it will fallback to the appropriate registry
> file

Good.

***

Which TB versions used a registry ? v1.0 ? v1.5 ? (not v2.0 nor v3.0.)

Would it be possible, and interesting, to merge the data from the two files ?
Or, more simply, offer both/separated options ?
If I think about what I have in "Mozilla", the user testcase would be someone with newer profiles.ini profiles but also older "unmigrated (to newer TB)" profiles in registry.dat... Does this make sense ?
(That is a little theoretical for me, as I don't have an older TB anymore, and never did more than give TB a try.)

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Which TB versions used a registry ? v1.0 ? v1.5 ? (not v2.0 nor v3.0.)
No idea... probably earlier than 1.0.

> Would it be possible, and interesting, to merge the data from the two files ?

I think that would be dangerous. The new profiles.ini should contain sufficient information for the old registry to be properly redundant.

> Or, more simply, offer both/separated options ?

That would just be confusing to the user.

> If I think about what I have in "Mozilla", the user testcase would be someone
> with newer profiles.ini profiles but also older "unmigrated (to newer TB)"
> profiles in registry.dat... Does this make sense ?
> (That is a little theoretical for me, as I don't have an older TB anymore, and
> never did more than give TB a try.)

Nope doesn't make sense. If profiles.ini doesn't contain the full information, then the user wouldn't be able to access all of their profiles.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)

"Just" for the sake of discussion:

> (In reply to comment #4)
> > Which TB versions used a registry ? v1.0 ? v1.5 ? (not v2.0 nor v3.0.)
> No idea... probably earlier than 1.0.

Then, maybe we could simply drop this case ?
(Not mandatory if it works, but a little less code to maintain.)

Scott, could you confirm when TB (= Toolkit ?) moved from registry.dat to profiles.ini ?

> Nope doesn't make sense. If profiles.ini doesn't contain the full information,
> then the user wouldn't be able to access all of their profiles.

Theoretical edge case(s): the user uses/used both kind of TB, maybe to try a newer version, decided not to (fully) upgrade [but got a profiles.ini (left around)], and now tries moving to SeaMonkey ? ;-)

Comment 7

[Mark Banner (:standard8)]

Attachment: The fix v2

Ok, now I've been reminded how to Clone nsILocalFiles, this is a much better version.

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #4)
> 
> Would it be possible, and interesting, to merge the data from the two files ?
> Or, more simply, offer both/separated options ?

Afterthought:
I guess someone in such a case could eventually think that temporarily renaming profiles.dat would allow the migrator to use registry.dat... :-|

Comment 9

[[e-mail]]

Comment on attachment 267329 [details] [diff] [review]
The fix v2

>-  return GetProfileDataFromRegistry(thunderbirdRegistry, mProfileNames,
>+  // Try profiles.ini first
>+  nsresult rv = GetProfileDataFromProfilesIni(thunderbirdDataDir,
>+                                              mProfileNames,
>+                                              mProfileLocations);
>+
>+  if (rv != NS_ERROR_FILE_NOT_FOUND)
>+    return rv;
>+
>+  thunderbirdDataDir->Append(NS_LITERAL_STRING(REGISTRY_FILE));
>+
>+  // Then try the old registry format
>+  return GetProfileDataFromRegistry(thunderbirdDataDir, mProfileNames,
>                                     mProfileLocations);
> }
It looks a bit odd calling this local thunderbirdDataDir, because it's not always a dir, so maybe thunderbirdData would be better?

Comment 10

[Mark Banner (:standard8)]

Patch checked in with thunderbirdData mod -> fixed.