ADSM-L

Re: How to backup files containing Japanese characters

2000-01-06 17:08:38
Subject: Re: How to backup files containing Japanese characters
From: Andy Raibeck <storman AT US.IBM DOT COM>
Date: Thu, 6 Jan 2000 14:08:38 -0800
Hi Nathan,

Yes, this one is also near and dear to my heart...

The key is that if the file name contains characters that are not
in the native code page for the language version of NT that you
are running, then we won't be able to back the file up. For English
NT systems, any double-byte character is not in the Latin I ANSI
code page (1252), so ADSM/TSM can not back them up.

The existing support for Unicode is of very narrow scope, and is
intended only for the Mac namespace support.

You can rest assured that this is very high-priority item for us,
and that a solution is being worked on. I can not say when it will
appear, but it is still a ways off; I would not expect any
solution sooner than 4Q2000. The delay is not
because we are putting it off, but because it is a very complex
change that is much more easily said than done. NOTE: standard
disclaimer about this not being a formal announcement, etc.,
apply.

Regards,

Andy

Andy Raibeck
IBM
Tivoli Storage Manager Client Development
e-mail: storman AT us.ibm DOT com
"The only dumb question is the one that goes unasked."

Absolutely correct. One of my fav topics also. The only real workaround is
not to copy files from one NT server using a certain codepage to another NT
server using a different codepage. Depending upon how NT decideds to map
these characters into the Unicode codepage will dictate whether ADSM will
be
able to back them up. If NT maps into a private use range, then ADSM will
complain.

Alan and I have both posted quite often on this topic. Although ADSM does
support unicode, it's support is not complete. Until such time that it is,
these problems will continue. I believe that full unicode support for TSM
is
on the table, but I don't know how high on the list of priorities it is. I
did put in my 2 cents with Tivoli that I thought this was an important
design change, but we'll wait and see.

I've also ran into this problem with a remote control package called
Remotely Possible which creates a cache folder. From time to time Remotely
Possible created some files with very unusual chars. ADSM didn't just skip
the files, it caused an assertion failure within the program. The only fix
was to crank up the GUI, do a backup and then see where ADSM was dieing. It
was then a case of deleting the offending file(s). What was even stranger
was that when I tried to send the offending files to ADSM Development,
Outlook couldn't attach them to an email and pkzip couldn't zip them.. I
ended up copying them onto a disk and mailing it. Hmmm.. looks like ADSM
isn't the only program that has problems dealing with NT's implementation
of
Unicode, even Microsoft seems confused.

Nathan