I received several errors like the first that you mentioned.
01/10/1999 22:13:34 PrivIncrFileSpace: Received rc=167 from
fioGetDirEntries: \\wntdisk\e$ \homedirs\CCDV540\Doc4
Backups\Eudora
Folder\Help Desk Stuff\Remark?Ehelp
See this technote from Microsoft.
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) 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.
****************************************************************************
****************************************************************************
***************************************
In my situation I traced each of these files origins to the Apple Macintosh.
It then became clear what was happening.
I was able to resolve this issue with the client by upgrading to v3.1.0.6
and leaving the default setting for USEUNICODEFILENAMES which is YES. You
will not be able to backup these files if unicode support is turned off.
This error could also have stemmed from international characters in the
filenames. Once again the solution is to upgrade to v3.1.0.6, 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).
I decided to set USEUNICODEFILENAMES to YES as my filespaces contain a
mixture of the above cases.
Regards,
Nathan King
-----Original Message-----
From: Robert Jarry [SMTP:jarry AT UTS.CC.UTEXAS DOT EDU]
From: Robert Jarry [SMTP:jarry AT UTS.CC.UTEXAS DOT EDU]
Sent: Monday, January 11, 1999 4:20 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: NT backup failure
I am having problems backing up certain directories on a machine
running
NT 4.0 SP4, along with ADSM client Version 3 Release 1 Level 0.5
Final
Edition PTF IP21371 (Intel). The server is AIX Version 3, Release 1,
Level
1.5.
A particular user directory in a backup set causes the following
messages,
along with termination of the scheduled backup session:
01/10/1999 22:13:34 TransWin32RC(): Win32 RC 123 from
fioScanDirEntry():
FindFirstFile
01/10/1999 22:13:34 PrivIncrFileSpace: Received rc=167 from
fioGetDirEntries: \\wntdisk\e$ \homedirs\CCDV540\Doc4
Backups\Eudora
Folder\Help Desk Stuff\Remark?Ehelp
01/10/1999 22:13:34 ANS1256E Cannot make file/directory
01/10/1999 22:13:34 ANS4028E Error processing '\\WNTDISK\E$': cannot
create
file/directory entry
01/10/1999 22:15:20 ANS1512E Scheduled event 'NTGROUP' failed.
Return code
= 4.
The scheduled backup session does not continue on to process other
files on
the same drive.
The same set fails with the same messages when I attempt to back it
up
manually all by itself.
This set of files has "list" permissions for all but the file owner.
Why doesn't the job continue on and backup the rest of the drive,
skipping
the above files?
Thanks in advance for your help,
Robert Jarry
----------------------------------------------------------------------------
--
--
Robert Jarry email:
Robert Jarry email:
r.jarry AT cc.utexas DOT edu
Unix Services phone: (512) 475-9330
Academic Computing & IT Services
The University of Texas at Austin
|
