Closed Bug 51506 Opened 24 years ago Closed 9 years ago

Possible to create new profile from commandline with already existing profile name

Categories

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

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Future

People

(Reporter: bugzilla, Assigned: ccarlen)

References

Details

Attachments

(1 file)

I can do: [c:\]moz -CreateProfile "gemal c:\temp" [c:\]moz -CreateProfile "gemal c:\tmp" and there is a profile created in each directory. It should not be possible to create a profile with the name of an already existing profile. If it should a "-force" command line should have to be added.... The profile only shows as one profile in the Profile Manager.
reassigning to racham.
Assignee: putterman → racham
We need to do a ProfileExists() check and just inform the user about the same without creating a new directory and modify registry entries in this case.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
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.8. Under the current design, it should not be possible to create a profile with the same name as another. If done from the command line, this should print a warning and return an error.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
In a release build with no -console option, if we printed a message to the log window that the profile already existed, the message would not be seen. Maybe the thing to do would be to (1) not create the existing profile and (2) force the profile UI to come up.
A quick and good fix would just to show the Manage Profile screen.
The patch checks for the existence of the profile and will not create it if it already exists. Instead, the profile UI will come up. Also, got rid of the call to LoadProfilePrefs() when doing -CreateProfile. Since we're going to exit, why load the prefs? This patch also fixes bug 56587 since that was a 2-liner. Bhuvan, can you review?
Keywords: review
Conrad, One of the ideas when implementing this commandline option is to not to show any kind of UI (probably we may have to in error cases). What if we simply return when asked to create the existing profile..? any thoughts..? bhuvan
I think it would be better to just return an error but the problem is how to inform the user. In an optimized build, unless the -console option was on, the user wouldn't know what had happened. If only we had a better error reporting mechanism back in the caller of StartupWithArgs(). I discussed this with Seth. On the other hand, and only in the case of the -CreateProfile command, just returning an error and silently quitting might not be so bad. With -CreateProfile, the app is just going to quit anyway. If you argree, I'll rework the patch. Then at least it will be doing the right thing when we do have startup error reporting and in the meanwhile, won't be so bad.
I agree with you. Better error reporting is what is going to improve the experience. Because, with -createprofile option, we can ask app to create the same profile but ask it to place in a diffrent location. If we quit without telling user that the profile already existed (and possibly inform the profile dir name), user will be unser impression that the profile is created under the new location he/she provided inthe commandline. That is wrong. For now, we may live with quitting without mentioning anything..but we certainly want some popup to say that profile already exists. Unless you need this for some of what you are doing for embedding, we should wait and fix this in totality. In the meanwhile, you should go ahead with 2 liner fix you have to avoid multiple directory creation.
-> mozilla0.9 Bhuvan's right - we should wait until we have a mechanism to report startup errors and fix it then.
Target Milestone: mozilla0.8 → mozilla0.9
Target Milestone: mozilla0.9 → Future
Blocks: 56587
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 Still the same as original problem description
FYI, this bug is now fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=376684 the -createprofile can write out the path it created profile at It occurs to me that this opens up a possibility. If a user tries to create a new profile given a name that already exists, a profile with "-1" or some such could be created. In other words, the profile would have a different and non-conflicting name. Previously, there would have been no way to tell the user that this was done. Now there is a way to report the name of the profile created. The created profile's name goes out on stdout. IMHO, another bug could be filed asking that the Profile Manager UI come up to deal with this. If someone has done a "-createprofile", they are already launching from the command-line. They are going to do this and not enable the console? Why would they do that?
QA Contact: agracebush → profile-manager-backend
-CreateProfile no longer exists.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Still exists!
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
So it does. Sorry.
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: