I use a wrapper script to rsync to an nfs share. This runs from an fcrontab, so it is not unusual for files to be deleted while the script is running, for example if I remove a source directory after compiling it. The wrapper handles code 24 and the process is regarded as successful. Since 3.0.4 I'm sometimes seeing code 23 in this situation. The manual suggests that is a real error. I first saw it with 3.0.4 on x86_64, and initially assumed the error code had changed - until a run earlier this week gave me the previously expected code 24. Google has a number of postings for rsync code 23, all but one were from 3.0.4, the other was from 3.0.2. Most of them are just logs. Yesterday, I updated to 3.0.5 on x86 and tested. The command is rsync -aHx --delete --numeric-ids /home /nfs/staging/ . By untarring a package, starting the wrapper, then deleting the package 2 or 3 seconds later, I got: Thu Feb 5 22:35:23 GMT 2009 rsyncing rsync: link_stat "/home/ken/abiword-extras-2.6.6" failed: No such file or directory (2) IO error encountered -- skipping file deletion Today, I've repeated this adding -vvv to the command. The wrapper ended with sent 70132491 bytes received 810694 bytes 287801.97 bytes/sec total size is 13287948825 speedup is 187.30 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1040) [sender=3.0.5] _exit_cleanup(code=23, file=main.c, line=1040): about to call exit(23) but within the approx 100MB of output, the only thing I found which looked like an error was: rsync: link_stat "/home/ken/abiword-extras-2.6.6" failed: No such file or directory (2) I'm starting to think that perhaps this is caused by a missing directory, and/or there might be a race (because sometimes it seems to work as expected). The affected systems were using kernels 2.6.28 and 2.6.28.2, with gcc-4.3.2 and 4.3.3 and glibc-2.8 or 2.9.
I believe you are correct that this is caused by a vanishing directory. The code interpreting some link_stat() failures was changed in a recent release, and it looks like your use of -x caused the stat() of a vanished directory to cause an error 23 when it should have checked for ENOENT and handled it as a vanished file. I've checked in a fix for this. Thanks for the report!