APAR IC27346 discusses this problem. This was fixed in an
earlier 3.7.2.x patch, and the permanent fix went in to the
4.1.1.0 (and later) versions. I recommend that customers
use either 3.7.2.19 or 4.1.2.12.
I have included the text of the APAR below. Note that in the
"RECOMMENDATION" section of the text, it says to not apply
new maintenance until the fixing PTF is available. "Fixing
PTF" was a reference to 4.1.1.0, which was not available at
the time this APAR text was written. This fix was *not*
available in 4.1.0.x, so the point of this caveat was to
tell users who install 3.7.2.19 not to go to 4.1.0.x, but to
wait for 4.1.1.0 (or higher).
==================== BEGIN APAR TEXT ====================
ABSTRACT:
WINDOWS CLIENT CAN NOT BACK UP FILES WHOSE NAMES EXCEED THE
WINDOWS OS LIMIT OF 260 CHARACTERS.
ERROR DESCRIPTION:
Windows permits a maximum path length of 260 characters (259
usable characters plus 1 for the string terminator). However,
under certain conditions, the operating system permits files
of greater lengths to be created. As a result, when the TSM
Windows client attempts to access files whose path lengths
exceed the OS limit, the I/O operation fails with Win32 return
code 206 (ERROR_FILENAME_EXCED_RANGE).
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: Windows client on NT and 2000. *
****************************************************************
* PROBLEM DESCRIPTION: The Windows client is unable to process *
* files and directories whose names exceed the operating *
* system-defined length of 259 characters. *
****************************************************************
* RECOMMENDATION: Apply fixing PTF when available. Users of *
* fixtest 3.7.2.16 must not apply new maintenance until *
* the fixing PTF for this APAR is available. *
****************************************************************
PROBLEM CONCLUSION:
The Windows operating system defines a maximum path length of
260 characters (259 usable characters plus 1 character to
terminate the path). However, under certain circumstances, it is
possible to create files whose path lengths violate this limit.
When this happens, many programs, including Windows Explorer,
Notepad.exe, TSM, etc., can not access these files.
The Microsoft Win32 API file I/O functions provide a
circumvention to this problem that has been incorporated into
the TSM client. The client will now be able to support (i.e.
backup, restore, archive, retrieve) files that exceed the 259
character limit provided that the USEUNICODEFILENAMES NO client
option is in effect. If USEUNICODEFILENAMES is set to YES, then
the client will not be able to support these files.
The following information should be noted with regard to this
fix:
USEUNICODEFILENAMES NO must be in effect (as mentioned above).
If USEUNICODEFILENAMES YES is in effect, then these longer
file names are unsupported. Users should always use
USEUNICODEFILENAMES NO unless they have Mac volumes. If users
need to support both Mac volumes AND these longer file names,
then they will need to make provisions to run backups for the
Mac volumes separately from the non-Mac files, backing up the
Mac volumes with USEUNICODEFILENAMES YES, and the non-Mac
files with USEUNICODEFILENAMES NO.
The default value for USEUNICODEFILENAMES is YES when LANGUAGE
AMENG is in effect. For other LANGUAGE settings, the default
for USEUNICODEFILENAMES is NO. Thus when LANGUAGE AMENG is in
effect, users must explicitly code USEUNICODEFILENAMES NO in
their client options file.
The maximum supported length of the file name itself (not
including the directory in which it resides), is 255
characters.
The maximum supported length of the directory portion of the
path in which the file resides (not including the file itself)
is 1,024 characters.
The maximum supported length of any component within a
directory path can not exceed 255 characters. "Component"
refers to a part of a directory structure as delimited by the
backslash character.
To illustrate: Given a path of the form:
x:/comp1/comp2/comp3/filename
Each component "compx" can not exceed 255 characters.
Likewise, "filename" can not exceed 255 characters in length.
In addtion, "x:/comp1/comp2/comp3" can not exceed 1,024
characters. Paths whose components exceed any of these limits
are not supported.
Note: forward slashes are substituted for backslashes in the
above example because backslashes are not displayable in this
APAR text.
===================== END APAR TEXT =====================
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
From: Glass, Peter <Peter.K.Glass AT WELLSFARGO DOT COM>
One of our NT clients is getting a large number of 'ANE4018E ...: file name
too long' errors in their backups. The file names in question are indeed
quite long.
Does anybody know the TSM standard on file name lengths?
Can somebody point me to which TSM docs discuss this specifically?
Thank you!
Peter Glass
Distributed Storage Management (DSM)
Wells Fargo Services Company
> * 612-667-0086 * 866-249-8568
> * peter.k.glass AT wellsfargo DOT com
|
