Profile information is stored in the registry, which means that every time the registry is removed (typically every time a new tree is pulled, since the old registry isn't safe to keep around since it might contain pointers to the old libraries) we have to go through the profile wizard again. This means every day for a lot of developers. We need some way to avoid having to go through this! See bugs 6669 (linux) and 6022 (windows) for a related problem, that of storing the info in the build directory (but this one is a different problem -- even if you store the profile info outside the registry in ~/.mozilla, it's still in the registry file).

*why* is the list of profiles stored in mozregistry.dat? Partner companies have screamed enough about 4.5 putting the profiles in nsreg.dat, but the reasoning there was so we had a cross-platform location so Roaming would work. Using nsreg.dat for backward compatibility would be defensible -- we've given people registry code so they can find 4.5 Netscape profiles. If we're not going to be backward compatible with the registry library we've handed out then why put it in an opaque format at all? Use a simple text file or something else that can be recreated/modified easily by users. Or even just a separate registry file! There is no requirement that everything live in the same registry. The "Version Registry" is now physically separate from mozregistry for example.

dveditz is right on -- it makes much more sense to store the profiles as human-readable strings in a separate text file.

Strings won't work on a Mac, file representations have to be binary. To argue against myself the value of using the registry is that the code is XP, anything else leads to per-platform hacks. That may be OK if they are limited in scope.

Making profile information to live under mozregistry.dat (and other equivalents on other platforms) is problematic. We are going to have a new registry named as profileregistry.dat to store all profile related information. This way user will not any information and profile wizard will show up only at the right time.

This needs to move out one milestone. The new registry probably shouldn't be called the profileregistry, ask dp.

We need to: 1) decide if a new name is needed, 2) determine impact of the change, 3) parameterize all registry open calls, 4) create a profile manager member variable containing the name of our registry, 5) pass the member variable in for all registry opens. Moving to M9 since it's too late to do this for M8.

Reassigning to Gayatri. I think this will be fixed in M10 timeframe.

Moving the target fix version to M10.

P3s aren't going to make it in M10. Bulk moving to M11.

This bug has devolved to only changing the name of mozregistry.dat to something else. I propose profile.dat. Another alternative is to close this bug as INVALID...

This MUST be decided before beta or we'll be creating yet another migration hassle.

CC'ing dp and law. I suspect we will want a generic registry like mozregistry.dat -- while I certainly don't mind finding a better name profile.dat is pretty darn specific. If you're just going to rename your own call and not change the libreg default then I'm not going to stop you, but I don't know if that's a good idea. The 5.0 version registry needs to move back into a different registry from nsreg.dat and mozregistry.dat was the obvious choice. We will eventually (6.0?) have user-specific components that would be registered here, too.

The mozilla application needs a scratch pad (registry or not) to jot down information like this. And profile information could be stored there. Are we saying mozregistry.dat isnt that and is just something that is specific to xpinstall. If so, we need to figure out what that application scratch pad is. This aint about profiles, I think.

The bug is about renaming mozregistry.dat to profile.dat, which makes it non-intuitive if non-profile stuff ends up there. If the profile guys want to create a second registry I guess that's up to them but I'd recommend against it. Otherwise I have no problem changing mozregistry.dat to some other generic mozilla registry name.

Reassigning the bug to Bhuvan.

Dogfood Candidate

but this should be done before beta

I am *still* unclear what exactly this bug means. You can't "rename" mozregistry.dat to profile.dat because people other than the profile manager are using the file. Does this bug mean 1) create an ADDITIONAL registry named profile.dat --or-- 2) rename the shared mozregistry.dat to something else to break people's habit of reflex removals -- in which case what is the new name? (hint: not profile.dat)

Is mozregistry.dat the applications (apprunner) data registry or not. If it is, then maybe we can say data-registry.dat

*** Bug 17762 has been marked as a duplicate of this bug. ***

mozregistry right now contains only profile information. However the name change isn't really critical now. Setting the TFV to M13.

Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.

Putting dogfood in the keyword field.

Failure on launch for Win32 users

Failure on launch for Win32 users

Too late for this. Marking WONTFIX.

verified