doing -CreateProfile foo creates ~/.mozilla/foo/foo/* instead of ~/.mozilla/foo/* good news is that the profile will work fine. more good news: if I use the profile wizard, it does the right thing.

This is simple one. Will post the patch in the next update.

seems good to me. just curious, what happens if someone does this: mozilla -CreateProfile (no profile name or directory) it would be bad if the created profile with a directory that was the root of all the profiles. as bhuvan knows, if that was possible, we'd remove all profile directories if we deleted that one profile.

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.

Seems easy since Bhuvan provided the patch :-) As far as the point about mozilla -CreateProfile (no profile or directory), I have to look into that. Should that just be considered a command line error and we print a message and return, or use some unique default name. I would think it should be an error.

I did some testing on the 2001010108 PC Linux build while trying to test another bug, and came up with the following: ./mozilla -CreateProfile results in: ~/.mozilla/1/1/rxim3rlm.slt Wiped that directory, then ran ./mozilla: ~/.mozilla/default/5jt5k91d.slt After that, doing ./mozilla -CreateProfile results in the same behaviour as before. Running the command with argument yet another time creates the same directory structure, $HOME/.mozilla/1/1/rxim3rlm.slt. Running ./mozilla -CreateProfile testing generates: ~/.mozilla/testing/testing/zast4mey.slt The empty -CreateProfile result doesn't show up in Profile Manager. Hope this helps.

Correction to earlier: the "1" profile did show up in Profile Manager after I closed the browser to clean up the test cases. I noticed that if a profile directory is deleted, but appreg and registry aren't removed, the directory will be recreated on the next start. In the case of the tests, the duplicate foo/foo were created again, but without a .slt dir or default files. Deleting registry and appreg solves that problem; ~/.mozilla/default can be safely left during this.

Correction to earlier: the "1" profile did show up in Profile Manager after I closed the browser to clean up the test cases. I noticed that if a profile directory is deleted, but appreg and registry aren't removed, the directory will be recreated on the next start. In the case of the tests, the duplicate foo/foo were created again, but without a .slt dir or default files. Deleting registry and appreg solves that problem; ~/.mozilla/default can be safely left during this.

Thanks for the testing. Running ./mozilla -CreateProfile with no arguments should be an error. You need to specify the profile name and, optionally, the directory. That it creates ~/.mozilla/1/1/rxim3rlm.slt is very wrong. What should happen is that it should print an invalid usage error and dump the command line help. The extra dir that gets made when you do ./mozilla -CreateProfile testing is consistent with the original bug report.

A patch to fix this is on bug 51506 since that was also a -CreateProfile problem

-> mozilla0.9 :-(

-> 0.9.1

The updated patch does essentially what the original patch did. It just uses directory service differently in order to get an nsILocalFile with a temp variable and a QI. I looked into the case of somebody using -CreateProfile with no args. This should be illegal but nsCmdLineService, if no arg is given, will insert "1" as the arg and the caller has no way of knowing. So, if given no args, the name of the profile will end up as "1" Bhuvan, Seth - can you r=/sr=. While low priority, it's also low risk so I'd like to get it in and over with.

Whoops - typo on the last comment. The sentence which said: to get an nsILocalFile with a temp variable and a QI should have said: to get an nsILocalFile *without* a temp variable and a QI Bhuvan, Seth - how about some review?

r=bhuvan. Conrad, Do we have a separate bug on handling the error case when no profile name is provided as commandline arg ? If not, we should have one there. Option -createprofile has bunch of cases to take care of : 1. No commandline arg params are provided 2. Only profile name is provided (handled already) 3. Only profile dir name is provided 4. Is the profile name valid ? (checking for some special chars like ':', '/' etc) 5. Is the profile dir name valid ? (checking the patch validity) 6. Do we trim the trailing slashes on profile dir args ? 7. Handling the case when profile dir name contains spaces (like Program Files) May be all of these can go into one bug requesting to make -createprofile more robust..

> May be all of these can go into one bug requesting to make -createprofile > more robust.. Probably so. There are bugs on points 6 & 7. Point 1 is actually a problem with the commandline service. When it gets no arg, it quietly inserts a "1" and the consumer has no way of knowing that happened.

Moving out to 0.9.3, as I believe this isn't critical for 0.9.2.

Seth, you reported this one and I've asked you for sr= twice. What gives? I'm about to future it.

sorry ccarlen, sometimes things slip through the cracks. sr=sspitzer

Fixed checked in this morning before tree closed.

verified on branch build 2001072700 adding vtrunk reminder

verified on mozilla build 20010802 trunk build 2001080203 removing vtrunk