Very very long filenames

[itergo]

Hi,

we got user who named a file with the content of that file. Some files have 70 characters, with the path name it is all about 270 characters. But we no got only one file of taht type, no we got about 1700 files!!!
The Files are all on a NetWare 6 (SP1+NSS Patch+CIFS Patch) Volume secured by a Legato NetWorekr client in the version 4.21. We backup onto a Windows NT SP6 NetWorker Server in the version 6.1.2. The backup workes fine, but when you restore one of that long files into the original location, the server abended. When you restore the file into another location, for example the root, that works fine.
The User can´t see the files in their Explorer, so that they think that the files are lost and call the UHD to restore the files. You only can create these long files with Microsoft Office Programs, no other Program can create this nonsense.
Anybody ever had the same problem? Where is the error? On Legato or NetWare? One problem is the Office Product. Microsoft (a TAM) told me that the office suit is programmed to support 32k characters, the bad thing is that the OS that doesn´n support.

Stefan Bartels
ITERGO Hamburg, Germany

 

[BW78]

!Only nonsense!!

Mach es auf die harte Tour und lösche alle Files!
Danach führe wieder das altbewährte 8.3 Format ein

Hamburg, eine wirklich schöne Stadt! Nächstes Jahr komm ich wieder

Bastian WInkler
München

 

[Chapter11]

Courtesy of Babelfish...

nonsense!! Mach it on the hard route and deletes all files! Afterwards introduce again long-proven 8,3 the format Hamburg, a really beautiful city! Next year comes back I Bastian WInkler Munich

 

[jrryan]

Hi,

I have had exactly the same problem here. I was attempting to migrate the data from our NW4 SP9 servers to new NW6 SP1 servers.

Through much vigorous testing, I discovered that the abend occurs when Legato detects a conflict on the restore. If the conflict involves a file where the path including the filename is >= 255 characters, the server abends. In most cases, the conflict is incorrectly detected because the first 254 characters of a recover file are the same as that of a previously recovered file in the same location, even though the complete filename is different.

Further testing revealed that this is a problem on the NW4 servers as well. Unfortunately, there is a lot of data which is effected by this problem. Legato gave me several suggestions, including pushing the data from NW4 to NW6, pulling the data from NW4 to NW6, name space and compression checks, etc. Eventually we started going around in circles, so I had to look for other solutions.

I ended up installing BackupExec 9.0, and using that to migrate the data. Although this worked, the Legato problem is still unresolved. I would suggest contacting your local Legato rep, and pushing for a solution.

Hope this helps,