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)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: bugzilla, Assigned: ccarlen)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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
Assignee | ||
Comment 4•24 years ago
|
||
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
Assignee | ||
Comment 5•24 years ago
|
||
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.
Reporter | ||
Comment 6•24 years ago
|
||
A quick and good fix would just to show the Manage Profile screen.
Assignee | ||
Comment 7•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
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
Assignee | ||
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.
Assignee | ||
Comment 12•24 years ago
|
||
-> 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
Updated•24 years ago
|
Target Milestone: mozilla0.9 → Future
Comment 13•20 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
Still the same as original problem description
Comment 14•17 years ago
|
||
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?
Updated•15 years ago
|
QA Contact: agracebush → profile-manager-backend
Comment 15•10 years ago
|
||
-CreateProfile no longer exists.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Comment 17•10 years ago
|
||
So it does. Sorry.
Blocks: 1243899
Comment 18•9 years ago
|
||
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 ago → 9 years ago
Resolution: --- → INCOMPLETE
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•