Seems like rsync 3.0.0 daemon process will assert when using --append under certain circumstances. * This worked in 2.9.6. * Removing the --append option avoids the assertion. * Tried to make a test case using less rsync options, but the problem becomes harder for me to reproduce. OS: FreeBSD m3.npubs.com 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #3: Mon Dec 10 21:38:01 UTC 2007 sam@m3.npubs.com:/usr/obj/usr/src/sys/RACK3 i386 ASSERTION: Assertion failed: (CVAL(node->data, 0) != 0), function check_prior, file hlink.c, line 256. SERVER CONFIG (running with --daemon): syslog facility = daemon hosts allow = 10.2.4.0/29 log file = /tmp/rsync.log [d1] path = /data/d1/.store use chroot = yes read only = false write only = true uid = root gid = wheel CLIENT COMMAND LINE: /usr/local/bin/rsync -aREHx --inplace --links --ignore-errors --delete --delete-excluded --delete-during --exclude-from - --stats --progress /data/d2/comictrax.net/./ m3i::d1/comictrax.net SERVER LOG: 2008/03/11 16:48:08 [16408] connect from m2i.npubs.com (10.2.4.2) 2008/03/11 16:48:08 [16408] No match for refuse-options string "iconv" 2008/03/11 16:48:08 [16408] rsync to d1/comictrax.net from m2i.npubs.com (10.2.4 .2) 2008/03/11 16:48:08 [16408] receiving file list
Whoops, my command line was actually: CLIENT COMMAND LINE: /usr/local/bin/rsync -aREHx --inplace --append --links --ignore-errors --delete --delete-excluded --delete-during --exclude-from - --stats --progress /data/d2/comictrax.net/./ m3i::d1/comictrax.net
The latest dev source should have this fixed (e.g. git repository, latest "nightly" tar file). There were quite a few issues with skipped hard-linked files (via --append, --ignore-existing, etc.) that could cause problems (I saw both the assert error you cited and a hang). I also noticed that older versions of rsync were not doing the right thing in some of the option cases (e.g. hard-linking files into place that did not exist, even though --ignore-non-existing was specified). So, this should both fix the regression and improve several things. Thanks for the report! Also, as a bonus, I noticed this log entry was bogus, and fixed that too: 2008/03/11 16:48:08 [16408] No match for refuse-options string "iconv"