[<<]Message[>>]    [<<]Author[>>]        Subject        [<<]Thread    

Number   :  7919
Date     :  2004-05-19
Author   :  Kan Yabumoto
Subject  :  Re: Error 123 Unspecified System Error when copying
Size(KB) :  3



allen00x wrote:
>I am running a daily backup and I get a (## Error 123 ## Unspecified
>System Error) when copying files or directories with the Name
>containing Cyrillic letters. I am using these
>switches: /CK/E/I /H/KS/R /BI/C/V /ED /CR0/Y /PZ0/PN0 /ZE /F /oD3/oE3
>/oF1/oI3/oP3/oS3/oX3 /PB. Do you know a work around so that I can
>copy such files and directories?
>
>
>Example in Log:
>
>C:\s1\????.txt Copy failed
>--------------------------------------------------------
>Summary of Errors
>## Error 123 ## Unspecified system error
> C:\s1\????.txt

Currently, XXCOPY does not support unicode based file name
(all Win32 files are internally saved in unicode).

In a DOS Box (where XXCOPY resides), you may input and
the application can output only an 8-bit (ANSI) character
code. The first 128 characters are mapped pretty much
uniformly across code pages. But, the remaining (128)
characters are mapped to one of many variations which
depends upon the specific code page (different from one
language to another). When a file contains a unicode (2.1)
character (which can be any of nearly 50,000 characters)
that does not have its corresponding 8-bit character
in the code page, the character will be replaced by the
question mark (?) character. Normally, when the
code page of the DOS environment matches the code page
of the original console environment where the filename
was assigned, the DOS Box should be able to display the
character. But, in Windows' (non-console) environment,
there is no such restriction and you may specify any
Unicode character to a file. This is presumably the
main source of the filename display problem.

We plan to support unicode in XXCOPY in the future.
While it is relatively easy to support unicode internally
(inside XXCOPY), a regular DOS Box environment is not
equipped with the ability to display all 50,000 unicode
characters and therefore, we will continue to have
problem in specifying and displaying unicode characters
that are not mapped into the 8-bit character set that
is supported in the environment.

I believe having unicode-based directory names causes
a lot of problems in day-to-day file management operations.
E.g., the console-based operations (manual invocation
of console command and also batch file) must be done
using a string that consists 8-bit text. One scheme
we are thinking is that XXCOPY may accept external
files (for /CF, /EX) in unicode text (which can be
easily detected by the convention having the special
0xFFFE prefix character in Unicode file) and process
them accordingly. In the case of XXCOPY-generated
text file (for /ON/OA/Fo), we may invent a switch
that specifies the out file be in Unicode format.

That is, even if (and when) XXCOPY supports unicode,
if its output text is forced to use an 8-bit character
set, any unicode character that is not mapped to its
8-bit format in the given code page, the character
will be replaced with the question mark "?" (the
console output will always be in 8-bit and therefore,
you will see more of the "?" characters.

Kan Yabumoto



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.