Cannot backup folders with accented characters on Linux?

[mppit]

I'm not sure whether this problem lies with Retrospect Workgroup (latest version, with latest RDU), the Linux client (latest version), or with a Linux file system.

 

We have various folders on a Linux machine that contain accented characters in their names, such as "La Vita È."

 

When attempting to scan the drive where the folders exist, Retrospect gets to them, throws an error, and halts the scan:

 

While scanning volume /export/home,

Folder /export/home/dodonnell/Public/La Vita E/,

Scanning incomplete, error -24263 (file/directory not found)

 

When I ssh into the machine I can clearly see the folder's name in ls as "La Vita È" (Terminal is set to UTF-8 display) and accessing the folder and its contents is otherwise without trouble.

 

Renaming the directory to something without the accent 'fixes' the problem, but I know there are many other folders that could have accented characters in them and would prefer not having to force my users to change names now or override any application(s) that might create accented-character folder names in future.

 

The only reference to error -24263 I could find in the support area was from well over a year ago and allegedly was fixed. I searched the user-to-user fora and was unable to find any reference to the error number.

 

Any suggestions would be welcome. Right now this problem is preventing us from backing up important directories, so I'm hopeful a solution can be found and implemented soon.

[rhwalker]

Quote:

---

I'm not sure whether this problem lies with Retrospect Workgroup (latest version, with latest RDU), the Linux client (latest version), or with a Linux file system.

 

---

That's not very helpful version information, especially because these posts last a long time on the internet, so anyone searching the forums for an answer won't get meaningful information as to whether this problem has been solved with a later release of any of the components.

 

Anyway, I tested moments ago by making a root level folder named "La Vita È" on a PPC iMac (Mac OS 10.4.7), Immediate Backup, Preview (which caused the scanning phase on the client from the server):

 

Retrospect Workgroup 6.1.126, RDU 6.1.7.101 on Xserve G5 running Mac OS X Server 10.4.7

Client: PPC iMac with Mac OS 10.4.7 and Retrospect Client 6.1.130

 

Scanning worked fine, no issues. So, assuming that you've got the "latest version" of the Retrospect Linux client (Retrospect updates page indicates it's 7.0.110 of 2006-05-04), it would seem to be a Retrospect Linux client issue. I'd suggest that you file a bug report with EMC/Insignia/Dantz.

 

russ

[mppit]

Thanks. I'll file a bug report.

 

[Retrospect Workgroup for Mac OS X, v. 6.1.126; RDU 6.1.7.101; Linux client version 7.0.110]

[rhwalker]

Just as a further data point confirming that the bug is with the Linux client, I left the "La Vita È" folder on the iMac during the scripted networked backup tonight by Retrospect, and it went fine, backing up that folder and a "hello world" document inside of it.

 

All signs point to the Retrospect Linux client as the culprit, especially since everything works fine for you via ssh. Should be rather trivial for the Retrospect programmers to add the code change from the Mac client's code branch. ("just a few lines of code ..." - grin).

 

A possible workaround, especially if there are just a few of these directories and if they can be shared, might be to mount the Linux volumes as a share on the Retrospect Workgroup machine, back them up that way (and define other stuff as subvolumes, back those up safely from the Linux Retrospect client). A user in one of the other forums mentioned a clever hack for SMB that might be useful here, namely, putting a mount/unmount into the Retrospect Event Handler AppleScript on the Retrospect Workgroup machine so that the Linux volume gets mounted before backup and unmounted afterwards. If they can be mounted as AFP 2.0 or better, that would be great, but SMB might work, too.

 

Good luck, hope this helps.

 

Russ