100344 - Installation failed when creating directory with chars. outside the repertoire of the default system locale

Status: RESOLVED FIXED

(Core :: Internationalization, defect, P3)

Description

[Rui Xu]

Build: 2001-09-18

Steps:
1. Start installer, follow the steps till Setup Type dialog appears.
2. Click Browse button to bring up Select a directory dialog.
3. To create a new install directory, enter the double-byte characters into 
Directories box as attached files (the characters are entered using Phonetic 
and Korean (Hangul) IME). 
4. Click OK, look at the directory name.
5. Click Yes, look at the error message.

Actual: 
1. The double-byte directory name is garbled in Step 4.
2. Got the following error message in Setp 5:
"Could not create folder: xxxxxx  Make sure you have access to create the 
folder."

Comment 1

[Rui Xu]

Attachment: directory name entered with Phonetic IME

Comment 2

[Rui Xu]

Attachment: directory name entered with Korean (Hangul) IME

Comment 3

[marina]

same would happen if the dir contains non-ascii chars, and i think that we had a
bug on it.

Comment 4

[ji]

Rui, are these problematic chars the same as those you discovered in window 
title display problem (bug 94011 and bug 94024)?

Comment 5

[Rui Xu]

Yes, I tested with the same problematic chars in bug 94011 and bug 94024 so 
far, to keep the problem clearly and avoid any confusion. But, please 
note that the problematic chars are not only one or two.

Comment 6

[ji]

So it seems we have a generic problem with those extended Chinese and Korean 
characters. Could you check if it happens on file dialog window when selecting 
File | Open File on navigator window in case that the folder name contains those 
characters? Thanks.

Comment 7

[Yuying Long]

I agree with Xianglan, looks like we couldn't handle those extended Chinese and
Korean characters in any where of our application.  I believe you have some more
bugs about it, they may all caused by a same reason.

cc Frank.

Comment 8

[marina]

i take back my comment about non-ascii chars, the install doesn't fail with
those char in the path, at least on Win2K and XP

Comment 9

[marina]

here is a bug i was talking about that was verified as fixed, # 58866. Rui,
please read the lenghty discussion there and see if those bugs are related. 

Comment 10

[Rui Xu]

Xianglan, I tried to select File | Open File on navigator window, it has no
problem. In this case, navigator calls system functions.

Marina, thanks a lot for letting me know bug# 58866. I am trying to locate
all those bugs in our product and these information are very helpful.

Comment 11

[Rui Xu]

Xianglan, I forgot to mention that the navigator cannot pickup those 
problematic folder names from Open File dialog correctly after calling 
system functions. This bug will be sent separately.

Comment 12

[Roy Yokoyama]

dveditz/dougt: how could I debug the installer?
==== ccin'g dveditz and dougt

Comment 13

[Doug Turner (:dougt)]

samir or sean know how.

Comment 14

[Samir Gehani]

windows installer == ssu expertise

Comment 15

[Roy Yokoyama]

I used various Unicode WAPIs (eg. GetOpenFileNameW(), CallWindowProcW(),etc);
but none worked well.   

We really need to compile apps as an Unicode.  
Settign the milestone to moz 1.0 and lowering the Priority.

Comment 16

[Roy Yokoyama]

Note to reproduce:
- Install Chinese Traditional IME Phonetic in W2K-CS
- Type 'u'+'l'+ <Space> + page down + select 6th char

Comment 17

[Rui Xu]

Please also refer to bug 93507 and bug 93528 for detailed char input steps.

Comment 18

[Rui Xu]

Actually, it is difficult to fix these unicode issues with local APIs and 
patches since the problems mainly happened on the system layer. It might be 
better to improve the architecture for unicode support and fixing those unicode 
bugs.

Comment 19

[nhottanscp]

nsbeta1-
 works for default OS locale

Comment 20

[Rui Xu]

This bug also happened with CHT chars on CHT WinNT/Win2K, and KOR chars on KOR 
WinNT/Win2K.

Comment 21

[Frank Tang]

push to future

Comment 22

[Frank Tang]

problem on SCH OS can be addressed by bug 126744 and problem with korean
characters on KO os can be addressed by bug 126752

Comment 23

[Jungshik Shin]

bug 126744 and bug 126752 fixed the problem as reported originally, but it's
still impossible to install in a folder whose name includes a character outside
the repertoire of the current default system locale(that is, Hindi folder under
French locale on Win2k/XP. On Win9x/ME, it's impossible no matter what we do,
but on Win2k/XP, it's possible by fixing bug 162361 for which I have a working
patch.). I'm changing the summary line accordingly. 

Comment 24

[Wayne Mery (:wsmwk)]

jshin in comment #23:
> still impossible to install in a folder whose name includes a character outside
> the repertoire of the current default system locale(that is, Hindi folder under
> French locale on Win2k/XP. On Win9x/ME, it's impossible no matter what we do,
> but on Win2k/XP, it's possible by fixing bug 162361 for which I have a working
> patch.). I'm changing the summary line accordingly. 

is this fixed by bug 162361?
is bug 100243 a dupe?

Comment 25

[Jungshik Shin]

(In reply to comment #24)

> is this fixed by bug 162361?

No, it's not. bug 162361 is an important step forward, but  installer still uses nsILocalFile methods like 'SetNativeLeaf*' and Win32 'A' APIs extensively (even for text drawing)


> is bug 100243 a dupe?

No. The issue there was fixed a long time ago. Originally, it was a dupe, but I changed this bug for something else.

Comment 26

[Jungshik Shin]

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

Comment 27

[Jungshik Shin]

(In reply to comment #25)

> No, it's not. bug 162361 is an important step forward, but  installer still
> uses nsILocalFile methods like 'SetNativeLeaf*' 

I was just reminded by biesi's comment in bug 100364 that the installer does not use xpcom. So, the problem is its use of 'A' APIs instead of 'W' APIs.

Comment 28

[Simon Montagu :smontagu]

Is this fixed by bug 305039?

Comment 29

[(no longer active)]

(In reply to comment #28)
> Is this fixed by bug 305039?

I'm not sure if the original bug report was filed for the NSIS installer, but yes, the current installer on trunk and 1.9.1 branch can handle Unicode path names.