I've stumbled across a fairly obscure situation in which rsync hangs -- it just waits until I press ctrl-C. Here's a transcript. Note that directory 'foo' contains two small files that are hard-linked together, and have no read permission. ---------------------------------------------------------------------- $ uname -a Linux ferox 2.6.35-28-generic-pae #50-Ubuntu SMP Fri Mar 18 20:43:15 UTC 2011 i686 GNU/Linux $ rsync --version rsync version 3.0.7 protocol version 30 Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. $ ls -dl foo drwxr-xr-x 2 chris chris 4096 2011-06-09 23:23 foo $ ls -il foo total 8 15958048 --w------- 2 chris chris 193 2011-05-25 19:19 bd 15958048 --w------- 2 chris chris 193 2011-05-25 19:19 bd2 $ rsync -avv --hard-links foo /tmp sending incremental file list delta-transmission disabled for local transfer or --whole-file rsync: send_files failed to open "/home/chris/Dropbox/perlwork/brandysnap/foo/bd2": Permission denied (13) ^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(543) [sender=3.0.7] ---------------------------------------------------------------------- The hang doesn't happen if --hard-links is not specified, or the files have read permission.
Interesting. When the generator receives FES_NO_SEND from the sender (through the receiver), it is not noticing that the failed file is the leader for a hard-linked set, and thus it is not ever getting back to the first file in the set to (try to) finish it up. Thus, it hangs forever waiting for something to decrement the in_progress count on the file's file-list. I've checked in a fix for this. Thanks!