3.0.0pre2: bookend breakage (2 different errors)

[Erik Jan Tromp]

# The first error
rsync: generator.c:1867: check_for_finished_files: Assertion `flist != ((void *)0)' failed.
rsync: writefd_unbuffered failed to write 4092 bytes [receiver]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1493) [receiver=3.0.0pre2]

# Sample command, obfuscated to protect the guilty
rsync --archive --hard-links --no-motd \
  --numeric-ids --sparse --verbose \
  --link-dest $BACKUPPATH/hydrogen/monday/ \
  --link-dest $BACKUPPATH/helium/monday/ \
  --link-dest $BACKUPPATH/lithium/monday/ \
  --link-dest $BACKUPPATH/beryllium/monday/ \
  --link-dest $BACKUPPATH/oxygen/monday/ \
  --link-dest $BACKUPPATH/fluorine/sunday/ \
  --password-file $BACKUPPATH/fluorine/$BACKUPPASSWORDFILE \
  --temp-dir $BACKUPPATH/fluorine/ \
  rsync://$BACKUPUSER@fluorine:$BACKUPPORT/$BACKUPMODULE/ \
  $BACKUPPATH/fluorine/monday/ \
  &> $BACKUPPATH/fluorine/monday.log

# Background
I do rotating backups of the entire 'running' fs on all my linux
machines (ie: server data drives, ~/.ccache/, squid cache & suchlike all
excluded). Friday past, I installed rsync 3.0.0pre2 & upgraded
glibc-zoneinfo (slackware update that I finally got around to dealing
with) on all my machines. The next set of backups (00:00 Saturday)
immediately started throwing the above error, all in
/usr/share/zoneinfo/. Interestingly, the first machine in the set barely
made it 1/3rd of the way through this dir, second machine roughly 1/2
way, third machine further yet, fourth through sixth completed their
backups successfully.

The basic idea of my backup scheme is a 7 day rotating backup for each
machine (hostname/weekday). Delete the obsolete backup for the current
host, then --link-dest is used to link yesterday's set of the current
host 'forward' (making 'cp -al' unnecessary) while also linking today's
set of all other hosts 'sideways' to catch common updates. Simple,
effective, & it's worked for the past several years. You'd be amazed how
little space 42 complete sets of backups take when they're all
hardlinked together.

As a quick'n'dirty test, I removed all but the 'link yesterday forward'
--link-dest. Still threw the first error. When I added a 'cp -al' step,
added --delete-after, & removed all usage of --link-dest, it threw a
_different_ error without actually getting a chance to transfer any
updated files. Yay?

# The second error
Invalid file index: -101 (-1 - 0) with iflags 0 [receiver]
rsync error: protocol incompatibility (code 2) at rsync.c(273) [receiver=3.0.0pre2]
rsync: connection unexpectedly closed (21 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(596) [generator=3.0.0pre2]

# Sample commands, obfuscated to protect the guilty
cp -alf $BACKUPPATH/fluorine/sunday/. $BACKUPPATH/fluorine/monday/
rsync --archive --delete-after --hard-links --no-motd \
  --numeric-ids --sparse --verbose \
  --password-file $BACKUPPATH/fluorine/$BACKUPPASSWORDFILE \
  --temp-dir $BACKUPPATH/fluorine/ \
  rsync://$BACKUPUSER@fluorine:$BACKUPPORT/$BACKUPMODULE/ \
  $BACKUPPATH/fluorine/monday/ \
  &> $BACKUPPATH/fluorine/monday.log

I've undoubtedly left out some critical info, but I've been staring at
this too long. More, if needed, later.

Erik

-- 
"Failure is not an option. (It comes bundled with Windows.)"
"If at first you don't succeed, redefine success."