Bug 2615 - rsync hang when using -H
rsync hang when using -H
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.4
All All
: P3 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-14 14:44 UTC by Peter Fales
Modified: 2005-06-03 01:39 UTC (History)
0 users

See Also:


Attachments
Fix for sending a single file with -H (253 bytes, patch)
2005-04-15 01:05 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Fales 2005-04-14 14:44:27 UTC
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.
Comment 1 Wayne Davison 2005-04-15 01:05:53 UTC
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.
Comment 2 Wayne Davison 2005-04-15 01:29:26 UTC
Fix committed to CVS.  Thanks for the report!