Created attachment 128470 [details]
log file from installer
Using the NB 7.2 installer, choose a folder location that contains non-ascii characters, e.g. C:\Temp\Съ
The installation begin to deflate the contents and then halts with an error, see attached log for further details
The problem is with the Windows command prompt that cannot deal with other chars than ASCII. As you can see from the log. The installation failed on the unpack command which is executed via command prompt... So this issue is relevant for all Windows versions. The installer otherwise doesn't have problem with non-ASCII chars.
The best practice is to do not use non-ASCII char in folder names :)
On Ubuntu I can the IDE install to non-ascii folder - running the installer both on JDK 7 and on JDK 6 Update 38.
The fist fix in changeset: http://hg.netbeans.org/core-main/rev/2ed0df350708
Just for NetBeans IDE installer.
Now the user cannot install IDE to installation path with non-ASCII char.
The same has to be done for RCP app installer.
Fix for RCP applications installer: http://hg.netbeans.org/core-main/rev/6c6a5d44fd18
Integrated into 'main-golden', will be available in build *201301310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Libor Fischmeistr <firstname.lastname@example.org>
Log: #222846: non-ascii characters in installation path
(In reply to Libor Fischmeistr from comment #1)
> The problem is with the Windows command prompt that cannot deal with other
> chars than ASCII.
I think this statement is not true for all non-ascii characters. Windows command prompt can handle some non-ascii characters. I do not know the preconditions and set of characters that are allowed, but on my machine, Windows command prompt can handle e.g. German umlauts, such as 'ä', 'ö' and 'ü'.
With NetBeans 7.3, it was possible to install NetBeans (and NetBeans Platform based applications) to 'C:\äöü' and start from there, with NetBeans 7.3.1, this is not possible anymore.
The users of my NB-Platform-based Application used to do that. So I see this as an incompatible change. I would suggest to rework the bugfix so that a wider range than just the 7-Bit ASCII range is allowed to use.
Consider this bug fixed. Please do not reopen, rather file new issue.