ADSM-L

Re: ANE4018E : file name too long on AIX

2004-10-29 08:05:18
Subject: Re: ANE4018E : file name too long on AIX
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 29 Oct 2004 08:02:29 -0400
On Oct 29, 2004, at 6:32 AM, PAC Brion Arnaud wrote:
I got some bad looking messages on my TSM server (AIX 5.2.0.0  with TSM
5.2.2.1) yesterday, like :

10/27/04 19:55:52     ANE4018E (Session: 380998, Node: XXXXXXXXX )
Error processing '/fswas/was51/AppServer/installedApps/pacrs800Networ
k/AirWarder_1.6.4.16_train.ear/AirWarderScheduleEJB.jar':
file name too long(SESSION: 380998)

The client is installed on a AIX 5.2.0.0 and has version 5.2.0.0.
I can't understand why I'm getting those errors, as AFAIK, TSM is
supposed to handle long file names so far they're supported by the OS,
which is the case here !
Something else to note : this  AirWarderScheduleEJB.jar is not a file,
but a directory, so it looks like the TSM client is not searching
further in the directory tree, which is only one directory deeper, for
finding files to backup.
Someone having an idea on this ?

Arnaud - In that we haven't heard of this message for a long time, the
         problem may be with the file or file system itself.
As the (Unix) client manual says: "As long as the file system allows
creation of the file, the Tivoli Storage Manager client will back up
or archive the file."

I would do 'ls -aldx' on that file system object.  When dealing with
file names, what you see in a simple ls is not necessarily reality,
in that there may be binary crud in there, which the 'x' will reveal.

Your observation that the object is not a file is interesting.  A
.jar suffix is supposed to denote a Java ARchive *file*, not a
directory.  So something seems wrong there.

I would further examine the ls output to see if the object has any
unusual characteristics, perhaps being a hard link.  I would see if
'dsmc s' on it yielded different results than 'dsmc i'.  If so,
contact TSM Support to have them pursue.  You might also try boosting
the client level beyond base 5.2.0.0 and see if any difference,
before calling.

   Richard Sims

<Prev in Thread] Current Thread [Next in Thread>