Open Bug 51509 Opened 24 years ago Updated 2 years ago

spaces in profile directory in -CreateProfile doesn't work


(Toolkit :: Startup and Profile System, defect, P3)

Windows 2000





(Reporter: bugzilla, Unassigned)



(1 file)

this doesn't work:
mozilla.exe -CreateProfile "gemal c:\program files"
I'd expect this to create the profile directory gemal under "c:\program files" 
but it doesn't.
instead it created the profile directory under "c:\program"
reassigning to racham.
Assignee: putterman → racham
Target Milestone: --- → M19
We need to investigate more into the latest commandLineService services and see 
if we can do anyhting different...or we can introduce a new token like "," to 
separate 2 arguments which then allows us to avoid problems we have seen with 
spaces in the names of profile or profile directory..
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
Setting milestone. Easy to fix. Any opinions as to the syntax? Right now, the
delimiter between profile name and the profile dir is a space, with the result
you point out. Its awkward because -CreateProfile can have either 1 or 2 args. A
comma separator would work, or an additional arg such as -Dir. Any preference?
Target Milestone: --- → mozilla0.8
I think the syntax could be:
-CreateProfile "gemal" "c:\program files\mozusers"
Unfortunately, the nsCmdLineService is designed to have only 1 arg per cmd line
switch. Anything else is considered to be part of a list of URLs to open. It
couldn't handle -CreateProfile "gemal" "c:\program files\mozusers" This would
need to be broken up into two args or lumped together as one with the two
components separated by a specified delimiter. If we added an additional arg to
specify the directory, say -ProfileDir, it could be used with -CreateProfile as
well as -installer. It would be nice to specify the dir to which to migrate from
the command line.
-CreateProfile "gemal" -ProfileDir "c:\program files\mozusers"
is also very good.
-> mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
-> mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0
changing QA contact
QA Contact: gbush → ktrina
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 
Target Milestone: mozilla1.0 → mozilla1.0.1
Moving milestone.
Target Milestone: mozilla1.0.1 → mozilla1.5beta
*** Bug 231662 has been marked as a duplicate of this bug. ***
I think the current code that splits the -CreateProfile argument into two strings is a bit of a hack, and by making it work with an optional -profile argument you get all the goodness that -profile supports (e.g. relative paths).

I was considering even adding a -localprofile argument which gives you an override for just the local profile path.
Attachment #343447 - Flags: review?(benjamin)
Comment on attachment 343447 [details] [diff] [review]
Separate out the path into a separate argument

Existing code such as the unit-testing infrastructure relies on the current behavior (I originally changed it in FF0.9 and broke lots of stuff). I agree that the proposed behavior is better.

I would accept a patch to make -createProfile name -profile path work, but the old behavior also needs to keep working.
Attachment #343447 - Flags: review?(benjamin) → review-
QA Contact: ktrina → profile-manager-backend
-CreateProfile no longer exists.
Closed: 10 years ago
Resolution: --- → WONTFIX
No? seems to still be present.
Resolution: WONTFIX → ---
Flags: needinfo?(n.nethercote)
> cpp#2258 seems to still be present.

My mistake; I did a case-sensitive search for "CreateProfile". Sorry!
Flags: needinfo?(n.nethercote)
Component: Profile: BackEnd → Startup and Profile System
Product: Core → Toolkit
Target Milestone: mozilla1.5beta → ---
No longer blocks: 1243899
Assignee: ccarlen → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.