| Subject: | unicode.t tests fail on the Korean Vista with the strawberry perl |
<p>This is the related error msg from the perl/tk's 'dmake test' log.</p>
<code>
t\Tkxs.t ..................... ok
t\Trace.t .................... ok
t\trace1.t ................... ok
Can't copy Xcamel.gif to C:\Users\user\AppData\Local\Temp\OxtiUGNt52\隘
廻\??gif: No such file or directory at t\unicode.t line 67.
# Looks like your test exited with 2 before it could output anything.
t\unicode.t ..................
Dubious, test returned 2 (wstat 512, 0x200)
Failed 13/13 subtests
t\widget.t ................... ok
</code>
<p>As you see, the new directory name for the 'Xcamel.gif' is totally
screwed like '\隘廻\??gif'</p>
<p>I think this is because the test source code is trying to create a
file named "äöüß" which is illigal chars in Korean charsets. So, the
directory 'äöüß' becomes 隘廻 and file name 'äöüß.gif' becomes '??gif'.
The '?' character of the resulted full pass is an illigal character in
Windows file system, so the OS simply refuses to created the new copied
file. </p>
<p>Although the Vista internally use unicode-16 in its file system,
Vista OS seems to do some local char set to unicode translation when a
directory is created by 3rd party app like perl. This results in errors
like the one we have here when an app is trying to create a file name
with strange characters like 'ä', 'ö', 'ü', and so force...</p>
<p>I don't think there is a proper solution for this one other than
removing or disabling these tests when the OS is known to be Windows and
its kind. Installation can be forced though, but I hope there is more
smooth way for it:)</p>