56587 - mozilla -CreateProfile foo create ~/.mozilla/foo/foo/*

Status: VERIFIED FIXED

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

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[racham]

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

Comment 2

[racham]

Attachment: patch to delete the extra dir name

Comment 3

[(not reading, please use [e-mail] instead)]

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.

Comment 4

[racham]

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.

Comment 5

[Conrad Carlen (not reading bugmail)]

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.

Comment 6

[Mark Bialkowski]

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.

Comment 7

[Mark Bialkowski]

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.

Comment 8

[Mark Bialkowski]

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.

Comment 9

[Conrad Carlen (not reading bugmail)]

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.

Comment 10

[Conrad Carlen (not reading bugmail)]

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

Comment 11

[Conrad Carlen (not reading bugmail)]

-> mozilla0.9 :-(

Comment 12

[Conrad Carlen (not reading bugmail)]

-> 0.9.1

Comment 13

[Conrad Carlen (not reading bugmail)]

Attachment: updated patch

Comment 14

[Conrad Carlen (not reading bugmail)]

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.

Comment 15

[Conrad Carlen (not reading bugmail)]

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?

Comment 16

[racham]

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..

Comment 17

[Conrad Carlen (not reading bugmail)]

> 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.

Comment 18

[Radha on family leave (not reading bugmail)]

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

Comment 19

[Conrad Carlen (not reading bugmail)]

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

Comment 20

[(not reading, please use [e-mail] instead)]

sorry ccarlen, sometimes things slip through the cracks.

sr=sspitzer

Comment 21

[Conrad Carlen (not reading bugmail)]

Fixed checked in this morning before tree closed.

Comment 22

[Grace Bush]

verified on branch build 2001072700
adding vtrunk reminder

Comment 23

[Grace Bush]

verified on mozilla build 20010802
trunk build 2001080203
removing vtrunk