Sharon,
I've seen this error message before in a varitey of cicrumstances.
In this instance it appears that the client is attempting to backup a file
which appears to contain an invalid filename. On occasion NTFS will allow
the creation of filenames which appear to contain illegal filenames...
There is a technote from Microsoft about this behaviour which I have
included below.
Although this technote speaks specifically of Apple Mac filenames, it could
also pertain to any app which creates a character which maps into the
Private Use Area range of the Unicode Standard.
Since the ADSM Client 3.1.0.6 is NOT fully unicode compliant the backup
client think that filenames containing private use area characters are
invalid.
I've seen a number of posts about this problem. If IBM are going to attempt
to support unicode in the backup client why did they make a half baked
version of it?
If you're going to bulid in compliance for something it's got to be all or
nothing.. otherwise you end up with all these dumb problems.
There are some workaround although they don't work in all cases.
The only workaround which does seem to work without fail is renaming the
file. Personally I don't have time for this. I have over 1,000 clients and
don't have time to check the sched.log of each of these clients to see which
files it missed during the night. I'd be here till next year if I had to do
that. That plus the fact that users get upset when you rename their files.
If the file was created by an AppleMac then I found that the default setting
of USEUNICODEFILENAME YES fixed the problem.
This error could also have stemmed from international characters in the
filenames. However you can choose to make USEUNICODEFILENAMES YES or NO.
However if you choose YES it will appear that ADSM is backing up junk
characters in the filenames - this is because the ADSM Client is not yet
fully unicode compliant. Despite the junk characters that appear in the
backup you CAN still reliably backup and recover these files. When restored
these files look exactly as they did when backed up (with all accents
entact). This works most of the time, but not all of the time - there's
defnitely still some issues here.
Good luck,
Nathan
SFM Converts Macintosh HFS Filenames to NTFS Unicode
Last reviewed: December 5, 1997
Article ID: Q117258
The information in this article applies to:
Microsoft Windows NT Server versions 3.5, 3.51, and 4.0
SUMMARY
Microsoft Windows NT Services for Macintosh (SFM) makes it possible for
Macintosh clients to create filenames on SFM server volumes that appear to
contain characters that are illegal in NTFS filenames, but are legal
characters in Macintosh HFS filenames. These include the (ANSI) characters
0x01-0x1F and " * / \ < > ? | .
MORE INFORMATION
Because NTFS is Unicode-based, when a Macintosh client creates a filename on
an SFM volume, it must be converted from Macintosh ANSI to Unicode by SFM
before being passed to NTFS. Because SFM does the conversion, it can define
Unicode values that invalid NTFS characters will map to. It does so by using
the Private Use Area range of the Unicode standard.
The following list describes the Unicode character values that can be used
in NTFS filenames created by Windows NT applications that, when viewed by
Macintosh clients, will appear as the equivalent Macintosh ANSI "invalid"
NTFS filename characters:
Macintosh ANSI Unicode
-----------------------------
0x01-0x1F 0xF001-0xF01F
" 0xF020
* 0xF021
/ 0xF022
< 0xF023
> 0xF024
? 0xF025
\ 0xF026
| 0xF027
In addition, the following three characters are also mapped to the Unicode
Private Use Area:
Macintosh ANSI Unicode
-----------------------------------------------------------------------
Space (0x20) 0xF02
Space (0x20) 0xF028
only if occurring as the last character of the name
Period (0x2E) 0xF029
only if occurring as the last character of the name
Apple's apple logo character (0xF0) 0xF02A
A space or a period at the end of a filename is not legal in the Win32 name
space, but is common in Macintosh file naming practice. Hence, these are
mapped to alternate Unicode characters by SFM so that they are accessible by
File Manager and other Win32 applications. There is no Unicode equivalent of
Apple's apple logo character, therefore it too is mapped to the Private Use
Area.
Note: Remember that any unicode mapping done on a filename will make that
file inaccessible to windows 95 on other windows clients since only NT
supports unicode.
****************************************************************************
**********************************************************
-----Original Message-----
From: Rupp Thomas (Illwerke) [SMTP:thomas.rupp AT ILLWERKE.CO DOT AT]
Sent: Friday, March 05, 1999 12:18 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: AW: WinNT Client Messages
I had a similar problem yesterday. I had a look in directory
C$\WINNT\ and found a file with an invalid filename (the content
pointed to McAfee Virus Scanner).
I simply removed the file.
Regards
Thomas Rupp
> -----Ursprüngliche Nachricht-----
> Von: Sharon Combs [SMTP:swcombs AT US.IBM DOT COM]
> Gesendet am: Freitag, 5. März 1999 19:05
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: WinNT Client Messages
>
> I'm backing up a WinNT client using the 3.1.6 version and I'm
getting
> the
> following messages:
>
> 22:22:57 AltStreamSize(): CreateFile: Win32 RC=123
> 22:27:38 TransWin32RC(): Win32 RC 123 from NtSecurityRead():
> getSecurityDescriptor() for Owner SID SD
> 22:27:40 ANS1228E Sending of object '\\pmc01nasrv04\c$WINNT\?'
failed
> 22:27:40 ANS1256E Cannot make file/directory
> 22:27:40 ANS4028E Error processing '||pmc01nasrv04\c$\WINNT\?':
> cannot
> create file/directory entry
>
> Has anyone else out these seen this error and found a solution?
> Thanks
|
