Running command-line as follows: rsync --stats --modify-window=30 --links --hard-links --verbose --times -P -p \ --recursive --delete --exclude="known_hosts" --exclude=".Xauthority" \ --exclude=".ssh" /home/archive /backup/archive Get the following error message: rsync: hlink.c:480: finish_hard_link: Assertion `flist != ((void *)0)' failed. rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: unlink "/home/archive/Sermons_1/Music" failed: Is a directory (21) unexpected tag 107 [sender] rsync error: unexplained error (code 134) at io.c(1169) [sender=3.0.2] Rsync reports a failure when attempting to unlink a directory on the *SOURCE* side. I didn't ask it to delete *anything* on the source side. Holy crap! Unfortunately, the error is not repeatable. A repeat of the command finished the transfer without incident. This error happens about one out of 20 rsync runs. It's been present since rsync-3.0.0. I never saw anything like it with rsync-2.6.9.
In the latest source, the failing assert was replaced by some code that provides some error output prior to exiting. I also changed some code that was using a pool of buffers for the name to hard-link to instead use a buffer on the stack. We'll see if that helps us figure out the reason for the vanshed file list and see if it fixes the weirdness in the unlink you saw.
Any more info? If you still get an error, try the latest dev version (3.1.0 in git and nightly tar files) and specify --debug=hlink4 and let me know the output for a failure run. Also, specifying "--msgs2stderr" may help you to get errors back from the "server" side (which is the receiver/generator in a local copy). FYI, you'd use "-M --msgs2stderr" for a remote-shell copy (the option doesn't work with a daemon copy).
I've not seen the error since I upgraded to rsync-3.0.3pre1. But given the intermittent nature of the error (1 out of 20 runs or so), I didn't have much opportunity to observe the problem before I upgraded to 3.0.3pre2. And not much time on pre2 before upgrading to 3.0.3-final. It seems likely that the problem was fixed during the 3.0.3 development cycle, but I can't say for sure. Version 3.0.3 has behaved flawlessly for me, without even a single errant run, but it's only been a month. I've done perhaps a hundred rsync runs during that time. [Hmmm... If the bug were still present with a 5% probability of manifesting per run, there's less than a 0.6% chance that I'd get as far as 100 runs without seeing it. That's pretty darned unlikely. Perhaps we should close this bugzilla case out as "fixed". And in the unlikely event that I ever see it again, I'll try the extra options on 3.1.0 as you suggest.]
Good to hear! We'll mark this one as fixed in 3.0.3, then. Thanks!