26317 - Doing MigrateProfileInfo() all the time will have lots of side effects

Status: VERIFIED FIXED

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

Description

[racham]

In your recent checkins to nsProfile.cpp, I have noticed that 
MigrateProfileInfo()happens all the time. It used to be associated only with 
-installer option in the past. That way the transfer 4x info happens only at the 
install time or one can always run -installer option to get the 4x profile info.
Suppose you do migrate and rename a profile. You run the app again...you have 
all unmigrated profiles showing up. You delete a migrated profile, you run the 
app again, the unmigrated list shows up. Also, the mNumOldProfiles count is 
also affected by this.

I think we should simply leave it with -installer and have people to explicitely 
run that option, if they wish to get their 4x information. That should put 
things back in place.

Comment 1

[(not reading, please use [e-mail] instead)]

I'll check in the fix today.

Comment 2

[(not reading, please use [e-mail] instead)]

marking m14.

Comment 3

[racham]

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

Comment 4

[(not reading, please use [e-mail] instead)]

fixed.

sorry about that.

now, as before I broke it, the 4.x profile into only gets sucked into 5.0 when 
you run -installer.

Comment 5

[Grace Bush]

Seth, in build 2000020410- I migrate a profile, later delete or rename  it and 
then despite which option I use, the same profile (4.x name) shows up for 
migration.  Isn't this bug supposed to stop that except for -installer option?

Comment 6

[Grace Bush]

occurring on build 2000020709 also

Comment 7

[(not reading, please use [e-mail] instead)]

re-assign to gayatrib.

gayatri, please see gbush's last comments.

Comment 8

[selmer (gone)]

Is this still broken???  This should be a beta1 bug if it is!

Comment 9

[Grace Bush]

still occurring on beta build 2000031506 on win32

Comment 10

[gayatrib]

I did not see MigrateProfileInfo getting called in nsProfile.cpp anywhere except 
when using the -installer flag. 

One suspicion might be that when the installer team creates their executable, 
they might be invoking the profileManager with the -installer option to get the 
4.x profile info. 

But even if the installer team is using this, it should happen only at 
installtion time and not at every run to of the executable.

Adding ssu, cathleen to the cc list to see why this is happening. Not sure why 
this bug is assigned to me--I can pursue on it though.

Comment 11

[Sean Su]

The installer will call "netscp6.exe -installer" only at the end of the 
installer.  The shortcuts created afterwards to not have the "-installer" flag 
passed to netscp6.exe.

This does not look like an install problem if simply running netscp6.exe 
produces the same result as running it with a -installer.

Comment 12

[Cathleen]

profile manager shortcut is set with -ProfileManager

Comment 13

[Grace Bush]

I reproduce this using other shortcuts- -profilemanager or -selectprofile, 
testing rename is when I saw it...renamed a migrated profile and on  next test, 
the old 4.x name appeared.

Comment 14

[gayatrib]

I think the problem is that when Seth moved the MigrateProfileInfo call, it was 
still moved into one level above where it really belonged. I am posting the fix 
for this bug--this should go into both the BETA branch(version 1.120) and the 
tip(version 1.122).

This small code change should fix it. As Seth worked on this change originally, 
I thought it would be better if he checks in this fix. So re-assigning the bug 
to him. 

Also changing the keyword field in the bug to say beta1.

Here is the fix:
Index: nsProfile.cpp
===================================================================
RCS file: /cvsroot/mozilla/profile/src/nsProfile.cpp,v
retrieving revision 1.122
diff -c -r1.122 nsProfile.cpp
*** nsProfile.cpp       2000/03/12 08:55:04     1.122
--- nsProfile.cpp       2000/03/16 00:27:38
***************
*** 557,568 ****
        // Start Migaration activity
      rv = cmdLineArgs->GetCmdLineValue(INSTALLER_CMD_LINE_ARG, &cmdResult);
      if (NS_SUCCEEDED(rv))
!     {
!         rv = MigrateProfileInfo();
!         if (NS_FAILED(rv)) return rv;
!
          if (cmdResult) {
             PRInt32 num4xProfiles = 0;
              rv = Get4xProfileCount(&num4xProfiles);
              if (NS_FAILED(rv)) return rv;

--- 557,568 ----
        // Start Migaration activity
      rv = cmdLineArgs->GetCmdLineValue(INSTALLER_CMD_LINE_ARG, &cmdResult);
      if (NS_SUCCEEDED(rv))
!     {
          if (cmdResult) {
!             rv = MigrateProfileInfo();
!             if (NS_FAILED(rv)) return rv;
!
             PRInt32 num4xProfiles = 0; 
              rv = Get4xProfileCount(&num4xProfiles);
              if (NS_FAILED(rv)) return rv;

Comment 15

[gayatrib]

Re-assingning to Seth.

Comment 16

[leger]

Putting on PDT- radar for beta1.

Comment 17

[(not reading, please use [e-mail] instead)]

moving all m14 to m15.  

Comment 18

[(not reading, please use [e-mail] instead)]

I just tested, and checked in gayatrib's fix.

marking this fixed.  thanks for the patch.

Comment 19

[racham]

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

Comment 20

[Grace Bush]

verified on build 2000032109

Comment 21

[(not reading, please use [e-mail] instead)]

selmer / jar, do you want this checked into the beta1 branch?

Comment 22

[gayatrib]

Just checked in the fix into the branch.