Repeatable error -43 (file/folder not found) in network backup.

[hrobinson 0]

When I upgraded to OS X and new network clients (not sure exactly what version, this has been happening for a while, I just got around to reporting it), there are some files which it cannot back up. I just updated another client to use IP based backups and I am now seeing this on two clients. It appears that the presence of latin-1 characters in the file name is the necessary condition to reveal the bug.

 

In both cases, this happens in the first pass (data copy) not during verification. The backup program is 6.0.193 running on 10.2.8 and the clients are 5.1.157 running 8.6 and 9.x. All of the files were savable using early versions of Retrospect and Appletalk clients. It is 100% repeatable and puzzled me for quite a while until I got more than 3 files to look at. It appears that all the files that fail contain accented characters. I remember that OS X supports something like 50 different text encodings. I suspect that the OS 9 clients are returning one text encoding when listing directories and expecting a different one when opening files. Either that or the backup program is altering the character encoding when storing it in the catalog, but not converting it properly when opening files on the OS 9 client.

 

Up until now, what wasn't being backed up was just some of the flotsom that Apple's installer litters the drive with, but some of the files on the latest machine are mine and need to be backed up!

 

Can't read file “Résumé A”, error -43 (file/folder not found), path: “Traveler HD/Applications/ClarisWorks 4.0 Folder/ClarisWorks Stationery/Résumé A”.

Can't read file “Résumé B”, error -43 (file/folder not found), path: “Traveler HD/Applications/ClarisWorks 4.0 Folder/ClarisWorks Stationery/Résumé B”.

Can't read file “Résumé Cover Letter”, error -43 (file/folder not found), path: “Traveler HD/Applications/ClarisWorks 4.0 Folder/ClarisWorks Stationery/Résumé Cover Letter”.

Can't read file “Español”, error -43 (file/folder not found), path: “System A/Apple Extras/Mac OS Runtime For Java/License Agreement/Español”.

Can't read file “Patch für All Inst”, error -43 (file/folder not found), path: “Applications A/LOGIC 2.6 ƒ/General Support/Hardware Support/For Studio 5 Users / MTP-Mode/Studio 5 Modemport/Patch für All Inst”.

Can't read file “Patch für All Inst”, error -43 (file/folder not found), path: “Applications A/LOGIC 2.6 ƒ/General Support/Hardware Support/For Studio 5 Users / MTP-Mode/Studio 5 Printerport/Patch für All Inst”.

Can't read file “Español”, error -43 (file/folder not found), path: “System B/Apple Extras/Mac OS Runtime For Java/License Agreement/Español”.

Can't read file “Spered Santel Doué”, error -43 (file/folder not found), path: “Sessions/FLS/Spered Santel Doué”.

Can't read file “Spered Santel Doué Em”, error -43 (file/folder not found), path: “Sessions/FLS/Spered Santel Doué Em”.

[gkowalsky6 0]

I have similar errors on several clients where upper ASCII and 2-bit characters (Japanese) were used in file names, while the OS was plain US version. The same problem my users have with Symantec AV CE - the files can not be accessed or decompressed during the scan. I believe that everything: language-specific OS, Retrospect and applications required in order to get these files properly backed up.

 

The only workaround I found was to warn the users not to use non-English characters and _non-cross-platform_ characters (slash, backslash, dollar sign, percent sign, control char, asterisk, etc.) in file/directory names. If the application uses these, I'm suggesting to the users rename these files manually from directory window or from the shell. In mean time, the only problems I encountered were files with restricted rights (some weird PDF, Office and eBooks where the files' hashes were involved, some DRM issues, etc.)