Closed Bug 28962 Opened 25 years ago Closed 16 years ago

Name conflict with unmigrated profile needs better dialog

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: scott, Assigned: ccarlen)

Details

I had been using M13 until recently, when I started using the nightlies again.
Ever since, I've not been able to create a new profile using the name I used
before ("Scott").  This is even after deleting mozregistry.dat and the \bin and
\Users50 directories.  I thought all profile info was stored within these
locations?  It's not major as I can pick any other profile name and function
(which, incidentally, DOES become available again when the above-mentioned are
deleted).  But it's probably something that should be fixed.

Still happening as of build 200002216
this sounds like a problem we've experienced or heard about before, either in a 
bug or in chit-chat. reassigning to selmer. 
Assignee: ben → selmer
Component: Profile Manager FrontEnd → Profile Manager BackEnd
Scott,

Do you have any profiles from Netscape 4.5 or greater?  If so, is it named 
"Scott"?

Otherwise, deleting the mozregistry.dat file should have been sufficient to 
clear this up...
Yes, I keep Communicator 4.x around for times when Mozilla isn't doing the trick, and yes, my profile there is called "Scott" too. I thought about this, and had tried just renaming the Scott profile dir under 4.x (which didn't help any), but if you're saying this is the problem, then obviously one has to do more :). Also, I've kept 4.x installed with the same profile name and been using milestones and nightlies for a long time without any profile conflict between Mozilla 5 and Communicator 4... what got changed? Must have happened soon after M13. If there's now a profile name conflict now between Communicator 4 and Mozilla 5 and one just needs to keep different profile names, I can live with that for the time being... although I'm not sure I see why there should be a conflict (I can see all sorts of reasons why one would want both installed simultaneously, at least for a while).
Good.  The name of the directory isn't relevant.  The information in nsreg.dat 
is what matters in 4.5+.  If you run mozilla -installer, we'll ask if you want 
to migrate your old profile.  If you migrate, you get all your old stuff in the 
new profile.  This can be a big help if you're reading mail, have mail filters, 
or some other things that work but can't be set up using mozilla.

We're trying to avoid name conflicts, so we don't want a new Seamonkey profile 
to have the same name as an old 4.x profile.  The error message for this should 
be clearer.  I'm changing the summary to reflect the need for a proper error 
message and marking this confirmed.

post-beta1.
Assignee: selmer → racham
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Can't use profile name from M13 in nightlies → Name conflict with unmigrated profile needs better dialog
Target Milestone: M16
Great, I understand.  FWIW, I don't use the installer, but instead have used the
zipped version of the nightlies.
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
Target Milestone: M17 → M18
Bhuvan, is there an "improvement" to be made here, or is this already resolved?
Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
Setting milestone to mozilla0.9
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
-> future. Not a common problem (if even a problem)
Target Milestone: mozilla0.9.1 → Future
Keywords: mozilla1.1
Marking bugs related to migrating 4.x profiles as wontfix, as this is no longer supported.

If this bug isn't specific to 4.x, please reopen it.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.