User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Build Identifier: My username is Björn and I'm using swedish WinXP. Version 0.6 correctly saves/reads my user data in "C:\Documents and Settings\Björn\Application Data\Thunderbird" But Version 0.7 use "C:\Documents and Settings\BJöRN\APPLICATION DATA\Thunderbird" this causes all my accounts to diapear from the program of course and when I first start the program I am promted to create a news or mail account. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Benjamin, I've been getting a lot of complaints like this one with 0.7 about it no longer working with profile paths that contain 8-bit characters. I wonder if there are some charset bugs in the new profile code?

Can you attach your profiles.ini to this bug?

I couldn't find any profiles.ini, where should it be?

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

Ben G. I wonder if we should try to do a point release that addresses this if the fix turns out to be easy?

'ö' is U+00F6 and in Windows-1252, it's 0xf6 while in UTF-8 it's 0xc3 0xb6. 'ö' in Windows-1252 is '0xc3 0xb6'. So, what's happening is somewhere '0xc6' in ISO-8859-1 is converted to UTF-8 (0xc3 0xb6) and then is uppercased. After 'naive' (ASCII-only) case change, it has to be converted back to Windows 1252 (the code page of the system default locale) for the file operation, but it is not (as a result, 'ö' in UTF-8 (0xc3 0xb6) is interpreted as two characters 'ö' in Windows-1252) At first, I suspected bug 202366, but the patch there was committed a long time ago (on March 2nd, 20040. bug 226439 is another suspect (but not so likely). One place where I'm sure UTF-8 is interpreted as the code page of the system locale is nsWinShellService.cpp (http://lxr.mozilla.org/mozilla/source/browser/components/shell/src/nsWindowsShellService.cpp and bug 240272), but that's little to do with the profile path. Two other places to take a look at is nsLocalFileWin.cpp and SpecialSystemDirectory.cpp. All of these would have impact on places other than the profile manager as well. If it's not, it must be local to the profile code. I'll take a closer look at patches in bug 239929. reporter, can you try mozlla 1.7rc3 or 1.8alpha and see if it also has the same problem? This comment is in ISO-8859-1. I'd be writting this in UTF-8 if comment #0 were in UTF-8. Unfortunately, it's not so that to make both comment #0 and this get rendered correctly simulatneously, I'm adding this in ISO-8859-1. Btw, I agree with Scott about the need for a point release. This bug will make it all but impossible to recommend firefox/thunderbird to non-English speaking users (well, not all of them have non-ASCII user names on windows, but ...)

I tested Mozilla 1.7 Release and 1.7 RC3 and they don't have this problem.

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

Some Japanese people reported to Bugzilla.JP similar invalid path problem when "Japanese Login Name". Björn Carlsson, does the problem also occur on new profile creation? Or caused only by automatic profile conversion by installer?

OK, I think I may have a handle on this, but I'm still working to reproduce it. I think that this error is being caused by the profile-import code, which really doesn't get exercized in firefox at all (which is why all the dups are from tbird). In that code, I'm going through the old-style netscape registry to get profile names/paths (I reverse-engineered the old registry code, because I couldn't find any documentation). Apparently, I'm treating some data in there with the wrong charset: http://lxr.mozilla.org/mozilla/source/mail/components/migration/src/nsProfileMigrator.cpp#172 I think that, because of the strange way nsIRegistry works, this data is being written in UTF8. So we need to do a utf8-ucs2 conversion and use the nsILocalFile.initWithPath method, instead of initWithNativePath. If my diagnosis is correct, this will not affect newly-created profiles, it will only affect profile-import from previous thunderbird versions. Can someone verify that new profile work correctly?

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

This bug affect not only the user names but the whole user profile path. On Czech Windows the %APPDATA% is called "Data aplikací". After instaling tbird 0.7 and migrating profile from 0.6 the profile folder is moved into "Data aplikacÃ-". Newly-created profile works correctly. Somebody with enough karma please change the Summary.

I can reproduce this in Firefox also. If I have an existing profile made with a pre-AVIARY Firefox build, I used the build from 2004-04-18, and start the earliest AVIARY branch build I could find, 2004-05-20, the attached profiles.ini is created in C:\Documents and Settings\Björn\Application Data\Firefox\. The existing profile is not used, instead a new set of profile files are created in C:\Documents and Settings\BJÖRN\APPLICATION DATA\Firefox\Profiles\default\rxq11wsl.slt. This bug do not appear if I do not have an existing profile when I launch the 2004-05-20 build. I can even use the Profile manager to create a new profile in some other place under \Documents and Settings\Björn\. The full path is saved in profiles.ini, and Firefox have no problem in finding it.

This is untested, because I don't have the thunderbird trees to try it.

Comment on attachment 151541 [details] [diff] [review] Use unicode r=jshin While you're at it, why don't you do the same in browser/mail/components/migration/nsProfileMigrator.cpp? It has the same code that leads to the same problem as confirmed by Pawell. BTW, I'm wondering why the treatment of OS X case is different between browser and mail. We have to look into that problem in a separate bug.

benjamin, I'm going to check this into the aviary 1.0 branch right now so we can see if we can get some volunteers on non English systems to test it for us. I don't have the ability to test this either since I use an English system.

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

I think that "Release Notes" of Firefox 0.9 & Thunderbird 0.7 should be revised as soon as possible - describe this bug's problem with workaround(edit profile.ini) in "Known Issues" section. It is not too late, I believe. When release notes is revised, announce it for translaters, please. If 0.9.0.1 or 0.7.0.1 will be released soon, ignore my request, please.

(In reply to comment #15) > While you're at it, why don't you do the same in > browser/mail/components/migration/nsProfileMigrator.cpp? It has the same code > that leads to the same problem as confirmed by Pawell. It should be browser/components/migration/nsProfileMigrator.cpp.

For your information, it's fully possible to create a user account like Björn for example on an English Windows version. Referring to comment #16.

(In reply to comment #16) > I don't have the ability to test this either since I use an English system. Scott, problem is easily recreated on any case, (A) non-ascii username (B) non-ascii profile name, (C) non-ascii profile directry by user choice. I tested case (C) - ascii username/ascii profile name/Japanese directry name on MS Win-2K. (1) Create a profile by Thunderbird 0.6 - no problem. (2) Start Thunderbird 0.7. - profile.ini is migrated successufully. - profile is copied to directry of garbage in directry name. In case-C (probably also in cese-B), the garbage name is always used, even when profile is newly created one by Thunderbird 0.7. This is probably Bug 202366 and/or Bug 229415.

a test build with this fix in it is now available: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-0.8/ThunderbirdSetup.exe If someone wants to help test that it works.

It looks like that it works.

I've verified that Thunderbird 0.7+ 2004-06-25(latest-08 branch)/Win-2K resolved the problem in ascii username/ascii profile name/Japanese directry name case. Japanese directry name created by 0.6 was migrated and used successufully. Newly created profile with Japanese directry name is also used with no problem. Thanks for quick solution.

Comment on attachment 151541 [details] [diff] [review] Use unicode asking for sr

we checked this in already removing the sr request this is fixed on the 1.0 branch, the trunk and the 0.7.1 branch

(In reply to comment #26) > we checked this in already removing the sr request > this is fixed on the 1.0 branch, the trunk and the 0.7.1 branch Thanks, but it was fixed only in TB part. Firefox has exactly the same problem and browser/components/migration/src/nsProfileMigrator.cpp has to be fixed as well. (see comment #15) http://lxr.mozilla.org/mozilla/source/browser/components/migration/src/nsProfileMigrator.cpp#361 Do we need firefox peer a?

Reopening. Not fixed in Firefox build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/2004062510.

identical to attachment 151541 [details] [diff] [review] but this is for firefox.

I'm not sure if I should call it a new bug or if this one's not solved yet. But when I try http://ftp27f.newaol.com/pub/mozilla.org/thunderbird/nightly/2004-06-25-12- 0.8/thunderbird-win32.zip with my Björn account (with existing profile) then I'm prompted to choose user profile, and if I choose default a message box tells my that I can't choose the profile "default" because it is in use... But if I try to start TB from an account with all ascii characters in the user name (also with an existing profile), I have no problems.

Björn: since this bug turns out to be in profile-migration, you might need to delete APPDATA/Thunderbird/profiles.ini so that it will exercize the import code again. Did somebody checkin the firefox half of this patch? Please note that the firefox half would only affect users who had a nightly build after 0.8 and before 0.9 (when we were using APPDATA/Firefox instead of APPDATA/Phoenix).

Comment on attachment 151751 [details] [diff] [review] firefox patch This patch is identical to the patch that already went in to aviary-1.0branch, trunk and TB 0.7.1 release except that this is for firefox.

Thank you Benjamin Smedberg (comment #31) after deleting profiles.ini Thunderbird 0.7.1 works fine for me.

can someone confirm this patch has been checked in on he aviary 1.0 branch and mark the bug with the "fixed-aviary1.0" keyword if they checked it in? thanks

Comment on attachment 151751 [details] [diff] [review] firefox patch asking ro a-aviary explicitly. In early July, I wrote a couple of times off-line to ask for that, but haven't heard back.

taking chofmann's comment as 'a to aviary-1.0', I checked this in to both aviary-1.0 branch and trunk.