Closed Bug 61030 Opened 24 years ago Closed 22 years ago

No profile migration when logged in as a different user

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED INVALID
mozilla1.0.1

People

(Reporter: serhunt, Assigned: ccarlen)

Details

This is for NT4.0

0. Have at least two WinNT user profiles
1. Have several Navigator profiles created by 4.x
2. Install NS6
3. Run it, see all the profiles, continue with migration
4. Quit, terminate Windows NT session
5. Log in as a different user
6. Start NS6

Expected result: all old profiles should be listed in the profile manager box.
Actual result: only Default is present.

This problem is curable by copying file registry.dat from
winnt/profiles/1st-user/application data over to
winnt/profiles/2nd-user/application data
A Profile Manager issue, not a migration issue.  Reassigning.
Assignee: dbragg → racham
Since the registry inforamtion resides under Application Data, this is no
surprise. When you looged in as a new user, your Application Data folder has no
registry file and hence no 6.0 related profiles.

Your 4.x profiles info should have been migrated automatically. Did you have
Default profile already before you ran NS6 on the new user login...? If yes,
then you can try deleting that file and run NS6 again that should get all 4.x
profile info and disply it in the profilemanager window.

Reassigning to Conrad.
Assignee: racham → ccarlen
But we don't have this registry file when first start NS6 after installation 
either. But still see all 4.x profiles ready to be converted.

I tried deleting registry.dat when logged in as a second user, and this didn't 
help.
Can anybody else reproduce this?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
using trunk build for 2001010204
and steps listed above, I see list of all 4.x profiles (user1 and user2)

login as user1, Install and run N6 - I see all profiles as needing migration, 
migrate user1 and exit, logout of user1
login as user2, run N6 (netscape -installer to see 4.x profiles) - I see all 
profiles - including user1 as needing migration. 

When reporter started N6 (step 6), probably did not use -installer option and 
hence did not see the 4.x profiles- if you use the  netscape6 icon or profile 
manager icon on the first launch of a user, I don't believe unmigrated profiles 
will show  regardless which user launches. 


Reporter, try removing users50 and registry.dat for both users.
launch from DOS window with command netscp6 -installer as user1
exit and login as user2 and do the same from DOS window

True, I did not try -installer option. Is it well known way to do things, and I 
should leave the blame on my ignorance, or is it still a bug? I can easily 
imagine than an average user will just try the icon on the desktop and face the 
problem.
it was release noted....not sure how it should be handled
See mozilla home page/release notes link

"If problems occur during installation and your Communicator profile was not 
copied and converted, you can still use your profile. Launch Mozilla from the 
command line, adding the "-installer" option 
(that is, type mozilla.exe-installer" on the command line.) Or re-install 
Mozilla to see the profile manager dialog again."

-> mozilla 1.0
Moving this off. It doesn't seem like a bug but a mis-understanding. Not marking
invalid because there could be some confusing, less-than-ideal behavior on the
part of migration.
Target Milestone: mozilla0.8 → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
IF you are requesting that we list profiles from another OS account, then I
think this should be INVALID or WONTFIX. OS user accounts should be completely
independant and not interfere with each other. In fact, the other user should
not even have *access* to the data of the other account (enforced by the OS, so
there is nothing Mozilla could do about it).
Reading the original report, I think that it what's being requested and I agree
that it's invalid.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.