32808 - Profile is NOT create in selected directory

Status: VERIFIED FIXED

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

Description

[Henrik Gemal]

If you go into the Create Profile and press "Choose Folder..." select 
"C:\private\users\" as the folder and press "Finish" the profile is NOT create 
in the "C:\private\users\" BUT in c:\program files\mozilla\users50\"!!!!

Comment 1

[Grace Bush]

oops-saw this on trunk build too- 2000032109

Comment 2

[Matthew T (active 1999-2002)]

Reproduced on build 2000033114, MacOS 8.6. Platform/OS --> All

Comment 3

[don]

Steve, my guess is this is not Ben's bug ...

Comment 4

[selmer (gone)]

Reassign to Bhuvan, M16.

Comment 5

[Peter "jag" Annema]

The same on Linux build 2000040708. I tell it to create it in ~/.moz, it creates
it in ~/.mozilla anyway. Below some debug stuff grabbed (in folder: Undefined?).

Is this related to Mozilla starting the "create profile" for a second time? It
creates a second directory, Default User-1. The third time it starts fine, with
the second profile created. Using profile names One and Two didn't make a
difference.

----- One -----
*** IN ONFINISH
**** profName: One
*** going to create a new profile called One in folder: undefined
ProfileManager : CreateNewProfile
Profile Name: One
Profile Dir: 
before SetProfileDir
ProfileManager : CreateUserDirectories
ProfileManager : StartApprunner
profileName passed in: OneProfileManager : GetProfileDir
ProfileManager : GetProfileDir
~nsProfile

----- Two -----
*** IN ONFINISH
**** profName: Two
*** going to create a new profile called Two in folder: undefined
ProfileManager : CreateNewProfile
Profile Name: Two
Profile Dir: 
before SetProfileDir
ProfileManager : CreateUserDirectories
ProfileManager : StartApprunner
profileName passed in: TwoProfileManager : GetProfileDir
ProfileManager : GetProfileDir
~nsProfile

Comment 6

[selmer (gone)]

This appears to be one of those bugs where I was sleeping at the wheel.  
Actually assigning to Bhuvan now...

Comment 7

[racham]

*** This bug has been marked as a duplicate of 33752 ***

Comment 8

[Grace Bush]

ok

Comment 9

[Matthew T (active 1999-2002)]

*** Bug 33752 has been marked as a duplicate of this bug. ***

Comment 10

[Matthew T (active 1999-2002)]

Reopening after reversing dups. Bug 33752 was filed later, it had no milestone 
set, it didn't have any debugging info, it was incorrectly marked as Linux only, 
and it was assigned to Ben when [e-mail] had already said that this 
problem wasn't Ben's to fix.

Comment 11

[racham]

adding nsbeta2 keyword.

Comment 12

[racham]

ok......there are couple of issues here...

When a user selects folder of his/her choice...

1. In createProfileWizard.js (line : 94), we are asking for 
ProfileDir.rootFolder and that is returning a null (This makes the backend to 
fall back on the default profiles path).

Instead, when I changed it to ProfileDir.value, I get the folder name selected 
by the user. 

But, I know Ben has added rootFolder attribute with a purpose...So, he is 
going to lead this bug with a closure look.

_____________________________________________________________________________

As it seemed to returned the right value (folder name), I proceded to test with 
ProfileDir.value.

There are 2 cases here :

CASE A : Select root folder (like c:\ on windows, Hard Disk on Mac, / on linux), 
the filespec operations on Mac and Windows fail. Linux works fine.

On windows, when I select c:\ as my root folder, I get back c: from the 
filepicker. On the backend when an attempt is made to make a filespec out of c:, 
it fails and falls back to the default filespec i.e., CWD. Where as, if the path 
passed down to backend is c:\, it all works fine.

I spoke to pav. It looks like filepicker simply takes the whatever string it 
gets and wraps it with nsIFile and returns the same. So, nsIFile, here should be 
dong the right thing handing us back c:\ instead of c:. I logged a bug on this 
one (bug 38767).

On mac, filepicker returns Hard Disk, dougt thinks that is what is supposed to 
do in that case and it is right. But on the back end, conversion to filespec 
fails (profile backend is still using nsFileSpec, will be switched to nsIFile 
in M17) for the same reason as windows, Hrad Disk not being suffixed with ":". 
But what doug says is that if profiles backend uses nsIFile, it should not fail. 
So, I will have to add a hack to append ":" to the value passed to the backend.

CASE B : If you choose a folder under a root folder (like c:\foo or Hard 
Disk:foo), things on backend work just fine.

______________________________________________________________________________

If Ben discovers the role of rootFolder and brings it back to life, then we need 
to see if all these problems evoparate..

Reassining bug to ben.

Please let me know when the time and necessity comes along to add Mac Hack on 
the backend. I will do it right away. Adding dougt, pavlov and myself to cc 
list.

Comment 13

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 14

[don]

Move to M18.

Comment 15

[racham]

*** Bug 37331 has been marked as a duplicate of this bug. ***

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

1 line fix in hand. 

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

fixed. 

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

dont know how this got marked internal. 

Comment 19

[Grace Bush]

all platforms- builds for 20000615