Closed Bug 26317 Opened 25 years ago Closed 25 years ago

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

Categories

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

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: racham, Assigned: sspitzer)

References

Details

(Whiteboard: [PDT-]) 

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.
I'll check in the fix today.
Status: NEW → ASSIGNED
marking m14.
Target Milestone: M14
*** Bug 25991 has been marked as a duplicate of this bug. ***
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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?
occurring on build 2000020709 also
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
re-assign to gayatrib.

gayatri, please see gbush's last comments.
Assignee: sspitzer → gayatrib
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Is this still broken???  This should be a beta1 bug if it is!

still occurring on beta build 2000031506 on win32
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.
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.


profile manager shortcut is set with -ProfileManager
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.
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;



Re-assingning to Seth.
Assignee: gayatrib → sspitzer
Status: ASSIGNED → NEW
Keywords: beta1
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
moving all m14 to m15.
Target Milestone: M14 → M15
I just tested, and checked in gayatrib's fix.

marking this fixed.  thanks for the patch.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
*** Bug 32670 has been marked as a duplicate of this bug. ***
verified on build 2000032109
Status: RESOLVED → VERIFIED
selmer / jar, do you want this checked into the beta1 branch?
Just checked in the fix into the branch.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.