6909 - Rename mozregistry.dat to profile.dat

Status: VERIFIED WONTFIX

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

Description

[Akkana Peck]

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).

Comment 1

[Daniel Veditz [:dveditz]]

*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.

Comment 2

[Akkana Peck]

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

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[racham]

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.

Comment 5

[selmer (gone)]

This needs to move out one milestone.

The new registry probably shouldn't be called the profileregistry, ask dp.

Comment 6

[selmer (gone)]

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.

Comment 7

[racham]

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

Comment 8

[gayatrib]

Moving the target fix version to M10.

Comment 9

[selmer (gone)]

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

Comment 10

[selmer (gone)]

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...

Comment 11

[selmer (gone)]

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

Comment 12

[Daniel Veditz [:dveditz]]

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.

Comment 13

[Suresh Duddi (gone)]

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.

Comment 14

[Daniel Veditz [:dveditz]]

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.

Comment 15

[gayatrib]

Reassigning the bug to Bhuvan.

Comment 16

[selmer (gone)]

Dogfood Candidate

Comment 17

[daver]

but this should be done before beta

Comment 18

[Daniel Veditz [:dveditz]]

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)

Comment 19

[Suresh Duddi (gone)]

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

Comment 20

[leger]

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

Comment 21

[racham]

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

Comment 22

[leger]

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

Comment 23

[leger]

Putting dogfood in the keyword field.

Comment 24

[Nicole Mills]

Failure on launch for Win32 users

Comment 25

[Nicole Mills]

Failure on launch for Win32 users

Comment 26

[racham]

Too late for this. Marking WONTFIX.

Comment 27

[Grace Bush]

verified