home:~> ls -l foo bar -rw-r--r-- 1 mdubey users 0 Oct 20 00:03 bar -rw-r--r-- 1 mdubey users 4105 Oct 20 00:03 foo home:~> rsync -v foo bar/cuz wrote 34 bytes read 20 bytes 108.00 bytes/sec total size is 4105 speedup is 76.02 home:~> echo $status 0 home:~> ls -l bar -rw-r--r-- 1 mdubey users 0 Oct 20 00:03 bar I have seen this on Solaris (rsync 2.6.1), Redhat (2.6.1) and FreeBSD (2.5.6)
This has already been fixed in the CVS version, so it will appear in the next release. In currently released versions of rsync, the error is hidden unless -vv is specified, which is clearly wrong (as you discovered). It is easy to patch this fix into any version of rsync by looking for the stat() error in generator.c and removing the "if (verbose > 1)" check. The code will then look like this: rsyserr(FERROR, stat_errno, "recv_generator: failed to stat %s", full_fname(fname));
A side note in case anyone is interested: My custom rsync, in order to observe default ACLs correctly, needed a change to the behavior of "get_local_name". Even if only a single source file is being transferred to a single destination file, the receiving rsync changes into the directory of the destination file. (In fact, I found the idea of "local names" so confusing that I rewrote "get_local_name", adding additional comments and verbose output.) A side effect of the change is that, on my rsync, "rsync -v foo bar/cuz" will fail during file selection as it should. It says: rsync: push_dir#2.5 "/path/to/bar/cuz" failed: No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at main.c(498) rsync: connection unexpectedly closed (8 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(434) (I just realized that while the attempted push_dir is correct, the path in the error message is wrong: it should be "/path/to/bar". I'll fix this.) My rsync is available here: http://mysite.verizon.net/hashproduct/myrsync/