Hi Richard, First of all, thanks for your response ! Now concerning the tests your asked me to perform : 1) ls -aldx did not show anything abnormal -> only regular files, no links 2) selective backup : was successful !
To test further, I even tried to create a new file under that directory and to run an incremental backup : here again, no problem ... It looks like that problem can't be reproduced, or that it appears only during scheduled backups ... I'm going to wait until tomorrow (or better said Monday, as the W.E. is near), to see if this happens again, and react in consequence of the results ... Cheers. Arnaud ************************************************************************ ****** Panalpina Management Ltd., Basle, Switzerland, CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 Direct: +41 (61) 226 19 78 e-mail: [EMAIL PROTECTED] ************************************************************************ ****** -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Friday, 29 October, 2004 14:02 To: [EMAIL PROTECTED] Subject: Re: ANE4018E : file name too long on AIX 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