This has been niggling me for a while, but am only now getting around to
reporting it. I have reproduced the problem with rsync 3.1.0 and nothing
in the news file for 3.1.1pre2 looks hopeful...
In some filing systems it is possible to have symlinks which are themselves
hard linked, i.e. have a link count greater than 1. For example,
$ ls -ali /tmp/rsync-in/
total 40
4063036241 drwx------ 2 cet1 cet1 302 Jun 13 20:00 .
4033877245 drwxrwxrwt 11 root sys 1104 Jun 13 20:07 ..
4063674164 -rw-r--r-- 1 cet1 cet1 19 Jun 13 19:59 data
4068304496 lrwxrwxrwx 2 cet1 cet1 4 Jun 13 20:00 name1 ->
data
4068304496 lrwxrwxrwx 2 cet1 cet1 4 Jun 13 20:00 name2 ->
data
When copying these with -H, rsync gets more than a little confused:
$ rsync -aHv --delete /tmp/rsync-in/ /tmp/rsync-out/
sending incremental file list
./
rsync: link "/tmp/rsync-out/name2" => name1 failed: No such file or
directory (2)
data
name1 -> data
sent 184 bytes received 131 bytes 630.00 bytes/sec
total size is 27 speedup is 0.09
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1165) [sender=3.1.0]
And a repeat attempt after that (with /tmp/rsync-out populated by the first
attempt) is even more dire:
$ rsync -aHv --delete /tmp/rsync-in/ /tmp/rsync-out/
sending incremental file list
name2 -> data
name1 => name2
... and at this point rsync hangs! On breaking out, name1 and name2 in the
target directory are hard links to data - no symlinks to be seen.
All this is with Solaris 10_x86 systems, but I have no reason to believe it
is OS-specific. It certainly doesn't seem to depend on fstype (tmpfs as in
the toy example above, ufs or zfs) or whether the target is local or remote.
I have variants where -R is being used as well as -H.
Before trying to officially report this, I thought I would ask on this
mailing list whether anyone can reproduce the problem.
--
Chris Thompson
Email: cet1 at cam.ac.uk