When I use rsync to sync my music library (mp3s typically have spaces and other slightly odd characters in their names) from one intel-Mac running latest version of Mac OS X 10.4 to an external firewire drive connected to a PPC-Mac with the same OS version, rsync succesfully transfered a few hundreds of new file and verified several thousands of old files. However, it choked on a few folders with the following error message: building file list ... 8435 files to consider ./ .DS_Store 15364 100% 13.98MB/s 0:00:00 (xfer#1, to-check=8433/8435) Kid Down/ /Kid Down/.DS_Store 6148 100% 136.45kB/s 0:00:00 (xfer#2, to-check=7745/8435) rsync: recv_generator: failed to stat "/Volumes/music/Tied & Tickled trio/Aelita/08. Aelita 3.mp3": Input/output error (5) rsync: recv_generator: failed to stat "/Volumes/music/Tremolo Beer Gut/.DS_Store": Input/output error (5) Tremolo Beer Gut/From The Vinyl Archives Of/ rsync: recv_generator: mkdir "/Volumes/music/Tremolo Beer Gut/From The Vinyl Archives Of" failed: Input/output error (5) *** Skipping everything below this failed directory *** Tremolo Beer Gut/The Inebriated Sound Of The Tremolo Beer Gut/ rsync: recv_generator: mkdir "/Volumes/music/Tremolo Beer Gut/The Inebriated Sound Of The Tremolo Beer Gut" failed: Input/output error (5) *** Skipping everything below this failed directory *** Emmaboda 2007.3/
An "Input/output error" generally indicates a problem with the filesystem, operating system, or hardware, not with rsync. If you "stat" the problematic files manually at the shell, does that succeed? Can "cp" copy the files?
I could copy the files both with cp and using the GUI. I could also stat the files without any obvious error. Furthermore, I tested copying the directories in the receiving location, They where, not surprisingly, empty and duplicating them using cp appeared to behave normal. Both the source and destination directories are located on AES128 encrypted HFS+ disk images (.dmg) but I have had this sync job running every day using cron without any problems until now.
To be clear: can you successfully run the same "mkdir" and "stat" calls in the destination that are failing for rsync? Also, you might try fsck-ing the destination filesystem or even rebuilding it completely. This is not the first report of rsync incurring I/O errors that other file-copying programs don't. Still, I don't see a way to address the problem in rsync; it's not as if a change to rsync will make the errors go away.
I never tested mkdir on the remote system but stat was fine. However, after fscking the filesystem on the destination the problem was solved. A little weird, isn't it?
Good, so the problem was not with rsync.