After the upgrade to 2.6.4, we've found a number of cases where a command of the following form hangs: ./rsync -H user@remotemachine:/etc/remote_file /local/dir/ The problem goes away if -H is not used, or if the target is a file rather than a directory. It also goes away when the local machine uses 2.6.3 (and the remote machine uses either 2.6.3 or 2.6.4) gdb shows that it is stuck in an infinite loop at link 196 in hlink.c: while (!(file->flags & FLAG_HLINK_EOL)) { ndx = file->F_NEXT; file = FPTR(ndx); } Every time through the loop ndx is zero, and file always gets the same value. Unfortunately, it doesn't seem to be reproducible between all pairs of machines. In the cases where we've seen it, the local machine is solaris and the remote machine is Linux running Fedora Core 2, or RedHat 9, but it doesn't show up between all such pairs of machines. On the machines where the problem is showing up, however, it is completely consistent and reproducible.
Created attachment 1161 [details] Fix for sending a single file with -H The fix is to get rid of the attempted optimization where we don't look for matching hard-links if the file-list size has only 1 item in it. Doing this leaves the file's hard-link-data pointer set, which indicates to the 2.6.4 code that the item needs to be hard-linked to something. Allowing the single-item file-list to go ahead and do the normal hard-link init ensures that the singleton file struct gets its hard-link-data pointer cleared, and all is well.
Fix committed to CVS. Thanks for the report!