Since it's occasionally necessary to blow away your mozregistry.dat, it's convenient to be able to leave your profile directory in place, and just create a new registry entry for that path on the disk. The old profile manager used to let you do this, and I used it all the time. The new profile manager doesn't let you do this, and I think it should.

The right thing may be to prompt whether to link it up or to overwrite it. However, if we're doing a migration then the only choice should be overwrite. (Of course, cancel should be offered in both cases.) This is marked enhancement because the millions of consumer users will never do this.

> if we're doing a migration then the only choice should be overwrite Maybe, but I wasn't doing a migration. > This is marked enhancement The reporter owns the severity, and IMO this is not an enhancement, so I'm changing it back. > because the millions of consumer users will never do this I'd call it a regression because it's useful functionality that we used to have, and now we don't. As far as the millions of consumers, it doesn't hurt them to make this work as it used to, so I don't think it's right to couch it as nerds vs. consumers.

You are right....We use to allow users to use the same folder if it existed. Later, Part of the Seth's changes forced the profile directory name to be unique. Ideally we should be giving user an option to choose whether or not to use the existing profile folder. Couple of JavaScript changes (pop up window asking whether user wants to use the existing dir or not) and the supporting logic in nsProfile.cpp will be needed for this fix. Setting TFV to M12. Accepting the bug.

Will try to accommodate with the cleanup work I am doing. Moving the TFV to M13. Bug will be updated after the checkins.

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

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

I have added all the code required for this on the backend. Also, I have chnaged create createprofilewizard.js to see if the profile dirctory that user selected already exists. For now, if it exists, I am asking the app to just use it. But on the front-end, we should have a prompt dialog which says "do you want to use the same directory ?" and then pass the bollean value passed back from the confirmation dialog. If the user says ok, we use the existing dir otherwise we can create a unique profie directory for that profile. Reassigning to Ben. Adding myself to cc list. Ben please let me know if you didn't my additions to createprofilewizard.js

Move to M21 target milestone.

taking bug off Ben's plate

retarget to mozilla1.0

Here is one of the ways we can ask the confirmation from the user to use the existing directory or to create a new directory. This is when user tries to create a profile with a name with which a directory already exists (and ofcourse no profile with that name exists..) Index: createProfileWizard.js =================================================================== RCS file: /cvsroot/mozilla/profile/resources/content/createProfileWizard.js,v retrieving revision 1.31 diff -c -r1.31 createProfileWizard.js *** createProfileWizard.js 2000/11/04 16:28:46 1.31 --- createProfileWizard.js 2000/12/01 00:32:30 *************** *** 179,184 **** --- 179,189 ---- if (fileSpec != null && fileSpec.exists()) useExistingDir = true; + var commonDialogService = Components.classes["@mozilla.org/appshell/commonDialogs;1"].getService(); + commonDialogService = commonDialogService.QueryInterface(Components.interfaces.nsICommonDialogs); + + useExistingDir = commonDialogService.Confirm(window, "confirm", "Do you want to use the same directory...?"); + dump("*** going to create a new profile called " + aProfName + " in folder: " + aProfDir + "\n"); profile.createNewProfile(aProfName, aProfDir, langcode, useExistingDir);

This hasn't been touched in almost a year, just wanted to give it some spam, as this is an easy fix :)

Moving out to mozilla1.0.1. I'd put this in the really nice to have category

->default assignee

resummarizing.

seems to be related to bug 22689

Bug 77925 wants a profile manager option to link to/use an existing profile. I think it's a duplicate of this bug.

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

KW: 4xp ?

how can it be 4xp? as a simple check, i ran nc4 profilemanager there's no import mozilla/netscape4 profile option.

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

nc4 didn't NEED an import option, it would just find the profile and use it. One could drag practically anything into the Netscape users folder and it would work, which means that it was invaluable for collating different sets of mail files. The current situtation is a drastic loss of functionality, and my dad, who would have to be characterised as a newbie/consumer, has had to be helped with this several times. If Mozilla cares about home users this is something that would only be tolerated one time, and after that they'll start using something else. They won't even understand what's happening, because what Mozilla does currently is freeze halfway through the startup when it encounters a Profile it won't use. They'll just say, "this program is lame" and use something else. And THAT program won't have any trouble importing their prefs from Mozilla.

Suggestion: Could the salting be generated into another file instead of using prefs.js, which has lots of other settings, esp. since many of Mozilla's default settings are the opposite of what many people use (replying with the reply below, for example). So how would it be if when an outside profile is moved into the Profiles folder with the "wrong" salt, all one would do is remove a small file called prefs.slt and Mozilla would generate a new one using the original salt, which is unlikely to be guessed anyway. Mozilla itself could be set to do this. The security remains undiminished: there is still a salted file in the way of an attack, but a home user can easily discard the prefs.slt file or click on "Renew Profile" (new button which I made up...&^) in the Profile Manager to reestablish the old profile. The way it is now I have to go renew themes, sidebars, and preferences each time I migrate. Security and prefs should not be tied together in this fashion. Thanks for listening, I know you're all very busy, I want to "help"...AAAAAAAAAHHHHHHHHHHH!

We are eager to migrate away from Netscape 4 as mail client, however one BIG issue with Mozilla is this inability to import old profiles when they are lost or otherwise corrupted. To be exact we store the profile on a network drive with Netscape4, and all client PCs are configured to use the profile on this drive, which works with few errors and ensures the user the same profile regardless of the PC (and without Windowz' "roaming profiles"). With Mozilla this is impossible, since a random salt is created and there is no way to import an old profile into a new one, and no way to specify the directory in which to look for the profile.

One idea is to replace the salted figures with *'s (********.slt). This has worked for me when I needed to use an old profile for little bit longer before going through making a new one and manually migrating my Mail and Bookmarks files. This is bad security but good convenience...&^)

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

Why not start with some minimal import function e.g.: The user select's the directory of the old profile (with the *.slt dir), and then mozilla creates a new profile, and copy's the files with no paths in it e.g. *.s,*.w , bookmarks.html, cookies.txt and cookperm.txt ans so on to the new profile.

Not just for importing from old versions. When a system goes down, after re-installing Mozilla, trying to get old mail back is dificult. MS-Windows Mozilla seems to have an evolving place to store profiles, and does not auto import easily, as Netscape used to (this is probably due to uncertainty about which directory is *ACTUALLY* used *THIS* time - Windows has too many places to put the profile). Need an intuitive way to say "This is my old account, please create an up-to-date profile with this archived profile and collection of mails! Also handy, a way to import the archived mails from a profile. Can do this from Eudora or Outlook, but not from Mozilla!!!

Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com

Reassigning bug to owner and QA contact of selected component. Prog.

Actually, it seems like what the bug reporter wants is the ability to 'adopt orphan' profiles by adding them into the registry. BTW, will the bug still be valid after the toolkitization?

(In reply to comment #31 from 20 months ago) [...] > BTW, will the bug still be valid after the toolkitization? When run for the first time, or with the -migration command-line switch (which is not yet mentioned by "seamonkey -h"), SeaMonkey 2.0 (including the current trunk nightlies) will import any existing Netscape/Mozilla/SeaMonkey-1.x, Firefox and Thunderbird profiles (and let the user choose which ones, if any, to import). The "old" profiles themselves won't be modified but the "relevant" part of their contents will be imported into the newly-created Sm2 profile.

(In reply to comment #31) > Actually, it seems like what the bug reporter wants is the ability to 'adopt > orphan' profiles by adding them into the registry. The SeaMonkey team will not work on that. For import from 1.x to 2.x, we have a migration interface for that.