Closed Bug 6909 Opened 21 years ago Closed 20 years ago

Rename mozregistry.dat to profile.dat


(Core Graveyard :: Profile: BackEnd, defect, P2, critical)



(Not tracked)



(Reporter: akkzilla, Assigned: racham)



(Whiteboard: [PDT-])

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.
Target Milestone: M7
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.
Target Milestone: M7 → M8
This needs to move out one milestone.

The new registry probably shouldn't be called the profileregistry, ask dp.
Target Milestone: M8 → M9
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.
Assignee: racham → gayatrib
Reassigning to Gayatri. I think this will be fixed in M10 timeframe.
Target Milestone: M9 → M10
Moving the target fix version to M10.
P3s aren't going to make it in M10.  Bulk moving to M11.
Summary: Profile Wizard runs every time the registry is removed → Rename mozregistry.dat to profile.dat
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
This MUST be decided before beta or we'll be creating yet another migration
Severity: major → critical
Priority: P3 → P2
Target Milestone: M11 → M12
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.
Blocks: 12696
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.
Assignee: gayatrib → racham
Reassigning the bug to Bhuvan.
Dogfood Candidate
Summary: Rename mozregistry.dat to profile.dat → [Dogfood]Rename mozregistry.dat to profile.dat
Whiteboard: [PDT-]
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
 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
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. ***
Blocks: 18471
Target Milestone: M12 → M13
mozregistry right now contains only profile information.
However the name change isn't really critical now.
Setting the TFV to M13.
Target Milestone: M13 → M15
No longer blocks: 12696
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Putting dogfood in the keyword field.
Keywords: dogfood
Summary: [Dogfood]Rename mozregistry.dat to profile.dat → Rename mozregistry.dat to profile.dat
Target Milestone: M15 → M17
Target Milestone: M17 → M16
Failure on launch for Win32 users
Failure on launch for Win32 users
Target Milestone: M16 → M17
Target Milestone: M17 → M18
Too late for this. Marking WONTFIX.
Closed: 20 years ago
Resolution: --- → WONTFIX
No longer blocks: 18471
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.