When you log in Windows 2000J as Double byte user, you cannot create user profile in the default directory. Steps of reproduce 1. Create Double byte user name on Windows 2000J You need to set the user account for Double byte name by Administrator 2. Launch Profile manager 3. Click on Create Profile on the profile manager 4. Click on Next button 5. Enter the profile name, for example, test If you do not specify the folder name, it tries to create the profile in the default directory. The directory path shows as D:\Documents and Settings\test only. 6. Click on Finish button It does not do anything. Profile manager is looking for the directory, D:\Documents and Settings\<Japanese name user name for Windows 2000J>\Application Data\Mozilla\Users50\ Tested 2000-10-30MN6 and PR3 Win32 build on Windows 2000J.

Changed QA contact to teruko@netscape.com.

should this be nominated for RTM?

Yes. When I investigated Sony's problem, I came cross this problem. I nominate this for rtm.

Hmmmm, I don't think this is a front-end problem. Over to the back-end folks for evaluation ...

Profile manager is Bhuvan. It may be too late for this, there's already a lot of risky change in this area lately... I'm ok if you look for a small safe fix for this.

cc'ing nhotta

Windows 2000 JA is needed in order to reproduce (otherwise cannot input Japanese user name in the windows log in screen so cannot login). Adding yokoyama to cc, he has JA 2000.

racham<- can you point me to a right direction to get a head start on this issue? Thanks

Is this specific to W2KJ? Whatabout NTJ?

I don't have NT4J. Teruko-san, can you try it out?

This is reproduciable on Winnt 4.0J, too. On Winnt 4.0J, the default profile directory is D:\Winnt\Profiles\<Japanese User name> when I log in the NT as the Japanese User name. When I log in NT as the Japanese User name and create new profile as "default user", the directory path shows as "D:\Winnt\Profiles\default user" only. The path should be displayed as "D:\Winnt\Profiles\<Japanese User name>\Application Data\Mozilla\Users50\default user" Then, I click Finish button. It does not do anything. This is same behavior as on Windows 2000J. However, on Winnt 4.0J, when I type profile user name other than "default user" Netscape will create new profile under "D:\Winnt\Profiles\" On Windows 2000J, this does not happen.

Bhuvan, any hope of a safe fix for this? IQA, can you create a profile in a non-default location?

Yes. If user selects the different folder manually, Netscape will create the profile.

Teruko Comments : ___________ When I log in NT as the Japanese User name and create new profile as "default user", the directory path shows as "D:\Winnt\Profiles\default user" only. The path should be displayed as "D:\Winnt\Profiles\<Japanese User name>\Application Data\Mozilla\Users50\default user" ____________ If the machine is not password enabled, I can imagine it not to come up with "D:\Winnt\Profiles\<Japanese User name>\Application Data\Mozilla\Users50\default user". But then it should have been "D:\Winnt\Profiles\Mozilla\Users50\default user". So, we seem to failing to add "Mozilla\Users50" to the path we are getting from OS. That is strange. Roy, if you can look it up on japanese machine.. http://lxr.mozilla.org/seamonkey/source/modules/appfilelocprovider/src/nsAppFileLocationProvider.cpp#335 is the place where we get the App Data folder and append "Mozilla" and "Users50" down in that routine...Somekind of failure there must be stoping us even todo the right thing on clicking 'Finish' button. Also, youcan try printing out the value of aProfileDir in createprofilewizard.js to know what value you got... Adding Conrad to the list if he can see any place in the path that is not i18n friendly in directoryService/AppFileLocProvider..

Given the scenario, there isn't a clear place to identify where the things are going wrong...Need to debug on Naoki's machine. More updates later.. Roy, If you find anything in your debugging, please update the bug. thanks.

Problem in http://lxr.mozilla.org/seamonkey/source/modules/appfilelocprovider/src/nsAppFileLocationProvider.cpp#337 localDir contains an invalid PATH; thus it falls to use NS_WIN_WINDOWS_DIR. Investigating more.....

If you look at the lxr link Bhuvan gave, you can see that what we get back from directory service at that point should be "D:\Winnt\Profiles\<Japanese User name>\Application Data" It looks like we're not even getting that back from directory service if we end up with "D:\Winnt\Profiles\default user" I would look back to http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryService.cpp #1039

else if (iAtom == nsDirectoryService::sAppdata) fileSpec(nsSpecialSystemDirectory::Win_Appdata) returns fileSpec contains an invalid PATH. Investigating........

Got it. A call to MakeUpperCase(pBuffer) in nsSpecialSystemDirectory.cpp#142 causes the Japanese Folder name to be corrupted. Investigating...

Allright Roy! When this happens, back at http://lxr.mozilla.org/seamonkey/source/modules/appfilelocprovider/src/nsAppFileLocationProvider.cpp#337, do we get an error back? What about the existence test?

I've always thought that making paths upper-case was at least unsightly. I'm not sure why we need to do that. Maybe because nsIFile::Equals() on Windows uses case-sensitive strcmp. If the upper-casing needs to go, take a look at that as well.

Roy is on vacation (today & tomorrow). I am going to use his machine to see how far we can go if we have to skip the MakeUpperCase() requirement...and any other things we need to do.. Teruko, This morning when I could create the profile successfully on win2k and the folder location was D:\Documents and Settings...it is not able to pick up the path with japanese user name as some xpcom routines trying to converth the path into uppercase and corrupting the path as Roy mentioned. Were you able to do it on your test machine..? Also, can you list all the scenarios in which you fail and any possible workarounds (like picking a customized folder) in those cases on machine where user has logged in with japanese name. thanks.

Adding relnotertm, these users need to know how to avoid this problem.

Skipping MakeUpperCase() routine doesn't really help us much here...however, that will be one of the requirements to solve this problem as that process is corrupting the data. code point : http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsSpecialSystemDirectory.cpp#103 The path is still not true unicode as in nsFileSpec.cpp, we are doing a InitWithPath() to convert a FileSpec to nsILocalFile and we use GetNativePathCString which is also not good for i8n data. code point: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpec.cpp#1435 All these leads to a failure of total path conversion in nsProfile.cpp and hence only the path until the non-ASCII chars are encountered is used in constructing the path (that's why we see only c:\Documents and Settings\ and not c:\Documents and Settings\<i18n user name>\Application Data\Mozilla\Users50 as the default location for user profile folders). code point: http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#1192 Giving this bug to Conrad as he has been doing xpcom/io work lately and also profiles. Conrad, please let me know, if we need to redirect this to anyone else you know covering those areas.

I found out that behavior is different from the the Japanese user's privilege on the Windows 2000 system. I will test the different users to create new profile on Windows 2000J and Winnt 4.0J.

Sounds like the root of this problem is nsSpecialSystemDirectory because it is nsFileSpec based. Also nsDirectoryService.cpp because of its use of nsSpecialSystemDirectory. I'll ask dougt because he owns that.

I tested this in the different users privilege on Windows 2000J and Winnt 4.0J. 1. Japanese user name (Users) to log in Windows system 1.1 Windows 2000J Default users - In the profile manager, the directory path shows as D:\Documents and Settings\Default users only. Then, I click on Finish, but it does not do anything. 1.2 Windows 2000J Create test user name in profile - In the profile manager, the directory shows as D:\Documents and Settings\test only. Then, I click on Finish, but it does not do anything. 1.3 Winnt4.0J has same problem for both cases above. The path is different from Windows 2000J. It is D:\Winnt\Profiles. 2. Japanese user name (Power users and Administrator) 2.1 Windows 2000J Default users - In the profile manager, the directory path shows as D:\Documents and Settings\Default users only. Then, I click on Finish. It creates the profile, but it creates in D:\Documents and Settings\Default User directory. It should be created in D:\Documents and Settings\<Japanese name user name for Windows 2000J>\Application Data\Mozilla\Users50\Default user 2.2 Windows 2000J Create test user name in profile - In the profile manager, the directory shows as D:\Documents and Settings\test only. Then, I click on Finish. It create the profile directory under D:\Documents and Settings\<Japanese name user name for Windows 2000J>. It should be created in D:\Documents and Settings\<Japanese name user name for Windows 2000J>\Application Data\Mozilla\Users50\test. 2.3 Winnt4.0J has same problem for both cases above. The path is different from Windows 2000J. It is D:\Winnt\Profiles.

Racham<- I need to know where the conversion of the profDir from native char to Unicode happens. The unicode path is corrupted because the code (which I dont' know where) simply prefixes 0x00 to make an Unicode Char. In other words, where the ProfileDir gets assigned in: /profile/resource/content/createProfileWizard.js#109 For your previous comment, NativePathCString in the following file contains a valid Japanese char: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpec.cpp#1435 The corruption happens after this...

I think I have a fix for this. Basically, there need to have two fixes: 1) MakeUpperCase(pBuffer) 2) use of fileSpec.unicodePath in profileDisplay.setAttribute() I'll attach patches in a moment. Thanks Naoki and Bhuvan for your help.

Grace Bush and Teruko tested my local patch build on their respective machines and found no problems. Bob <- Should I check into the trunk?

Comments from Conrad above ( Carlen 2000-11-03 16:48 ), I took a look at the \\xpcom\io\nsLocalFileWin.cpp and found a couple of places needs to change to case-insensitive. Teruko- can you run the test again? I updated my local opt build. (\\royy- w2kj\mozilla-part3)

Roy, you seem to be moving along with this. While I can help with various nsIFile and file location issues, I don't have a 2-byte OS here and cannot test or verify. Should I assign this to you?

Sure, Conrad. Assign it to me. :)

-> Roy. Roy, there are several other 2-byte script issues in relation to file handling with which I could use your help.

Conrad <- I am more than happy to help you. What kind of other 2-byte script issues are you referring to?

Racham<-can you review the attached codes? I want to check-in. Thanks

r=racham. 2 of your changes are in xpcom. Please make sure you ran all pre-checkin tests and any other you think are appropriate with your changes.

Roy, the 1st patch removes the upper-casing, while the 3rd patch makes it do a case-insensitive comparison on Windows only. Have you tested your fix on Unix and Mac?

Naoki and Brian, could you please test the patch under Mac and Unix for me? Naoki-san <- Mac Brian-san <- Unix

I applied the patches. The buil is available on my Macintosh. Teruko, please try it.

Grace bush and I tested Roy's local build on Winnt4.0 (US and Japanese) and Windows 2000 (US and Japanese) as following procedure. Test procedure 1. Create English and Japanese user name (Users) to log in Windows 2000 system 1.1 Run the Profile manager to create the default users. You should make sure you can see the path name as D:\Documents and Settings\<Japanese user name for Windows 2000J or English user name for Windows 2000US>\Application Data\Mozilla\Users50\Default user" 1.2 Click on Finish button to create the default user. You should make sure the default user directory is created. 1.3 Run profile manager, then, rename and delete the profile. 2.1 Run the Profile manager to create "test" user for Windows 2000 US or create Japanese user for Windows 2000 J. You should make sure you can see the path as D:\Documents and Settings\<Japanese user name for Windows 2000J or English user name for Windows 2000 US>\Application Data\Mozilla\Users50\test or <Japanese profile name> 2.2 Click on Finish button to create the test user. You should make sure the test user directory is created. 2.3 Run profile manager, then, rename and delete the profile 3. Create English user name (users) for Winnt 4.0 US or Japanese user name (users) for Winnt 4.0J. Do the same procedure 1-2 on Winnt4.0J and Winnt 4.0US. The path is different from Windows 2000J. It is D:\Winnt\Profiles. You should make sure you can do all above. 4. Create English user name (Power users and Administrator) for Windows 2000 US and Japanese user name (Power users and Administrator) for Windows 2000J. Do the same procedure 1-2 on Windows 2000 US and Windows 2000 J. 5. Create English user name (Power users and Administrator) for Winnt 4.0 US and Japanese user name (Power users and Administrator) for Winnt 4.0J. Do the same procedure 1-2 on Winnt 4.0 US and Winnt 4.0 J. They worked fine in the local build. In Mac, there is another bug, 61552. Mac system does not have these admin issue. However, when the Japanese user creates the profile on Japanese mac system, Netscape does not find the Japanese "document" folder. Naoki and I tested Roy's patch on Naoki's Mac system. Profile manager detects the default path "<hard drive>\<Japanese document folder>\Mozilla\Users50". Also, I could create the new profile under Japanese folder name, rename the profile, and delete the profile.

In Linux, we should test creating the upper case profile user name and lower case profile user name. Brian, can you create local build for Linux?

Verified for Linux. To test this on my English Linux system I used kterm to create a directory with Japanese in the name (copy/pasted from browser: http://home.netscape.com/ja) and set my HOME environment variable to point to it. Without Roy's patch the Japanese part of the default directory string was corrupted and after clicking finish the profile was not created in the $HOME dir. With Roy's patch the Japanese part of the default directory string was fine and after clicking finish the profile was created in the $HOME dir. Teruko also tested that with Roy's patches upper and lower case names are created in distinct directories.

Teruko : I am little unclear about your comment. Did the patch also fixed the other Mac bug (#61552)?

Teruko : I am little unclear about your comment. Did the patch also fixed the other Mac bug (#61552)?

Roy, your patch is fixed the bug 61552. Basically the bug 61552 is the same bug as this bug. Profile manager does not know the default profile directory if the path contains the double-byte character.

Can someone /sr= for me? review is done by racham ( racham@netscape.com 2000-12-05 15:53 )

cc'ing dougt. doug: is this patch correct? It's doing case-insensitive compares in nsLocalFileWin.cpp.

It should be doing case-insensitive compares. Windows file system is case-insensitive. D:\foo == D:\FOO

looks good to me. perserve case internally, but compare without case. Please fix the other strcmp's while you are making these changes.

Adding nsbeta1 and intl keywords.

I believe the above patches only fix this particular instance of the test case. There are potentially other cases where the profiler may not work. (eg. If the user installs windows under a Japanese folder name, such as c:\<japanese dir>) Here is the new solution: - No need for 11/13/00 13:58 Removing MakeUppderCase() - Kepp the patch (11/13/00 13:58) for .unicodePath in js file - No need for 11/21/00 13:24 Making case-insensitive string comparison - No need for 12/19/00 13:24 As per request by dougt@netscape.com (2000-12-12 12:26). - Apply a new patch (see below). I fixed the MakeUpperCase() where it checks for double byte char. Can anybody review the code?

You shouldn't change MakeUpperCase, you should just remove it. It serves no purpose and bug 32056 is about the fact that it exists. Just get rid of it.

In other words, if MakeUpperCase is removed, it will fix bug 32056 as well. If not, I'll have to remove it anyway in order to fix that one.

Roy, your fix is not smart since it is not necessary for DBCS OS check code. It is no problem by the fllowing code. static char* MakeUpperCase(char* aPath) { // windows does not care about case. push to uppercase: int length = strlen(aPath); for (int i = 0; i < length; i++) { if (::IsDBCSLeadByte(aPath[i])) { i++; } else if (islower(aPath[i])) aPath[i] = _toupper(aPath[i]); } return aPath; }

Kato-san: I am sorry to say but I don't like your code. Your code checks for IsDBCDLeadByte() for EVERY char regardless of OS. It will be very slow. I made the code so that it has no impact on non-FarEast OSs. Please consider non-FarEast users as well. Conrad-san: I'm going to keep the patch for remvoving the MakeUpperCase(). (11/13/00 13:58). It fixes #32056.

Nothing has happened with this for a while. What's the story? Bug 32056 is still on my plate and removing MakeUpperCase would fix it.

/sr by ftang.

Checked in yesterday. (01/16/2001) Please verify. thanks

I verified this in 200101704 Win32 build with Winnt 4.0J and Windows 2000J.

verified US build for WinNT and Win2000 2001011706