While backing up an active PostgreSQL database, I occasionally get exit code 23 from rsync, accompanied by a error messages: rsync: read errors mapping "/data/postgresql/8.3/main/base/144458723/1009564226": No data available (61) rsync error: some files could not be transferred (code 23) at main.c(1058) [sender=3.0.3] As indicated by http://lists.samba.org/archive/rsync/2009-November/024133.html this is caused by the file being truncated while being read by rsync. On an active database this is actually a normal condition, as files are created, deleted and truncated all the time. Unfortunately the code 23 cannot just be ignored, as it also may indicate that there was an actual "real" IO error during the backup. And without reading rsync output there is no way to tell. So the proposal is to avoid generating ENODATA for truncated files and treat them similarly to vanished files.
Indeed. This is probably one of many kinds of concurrent modification to the source that rsync handles ungracefully. In general, when different system calls return inconsistent results, that could indicate either a concurrent modification or filesystem misbehavior. The downside to always assuming concurrent modification is that we miss the opportunity to report filesystem misbehavior if it happens. One example is the Cygwin "file has vanished" error with foreign characters in filenames ( http://lists.samba.org/archive/rsync/2008-January/019696.html ).