3.0.0pre2: bookend breakage (2 different errors)

Erik Jan Tromp betageek at sympatico.ca
Mon Oct 15 07:25:56 GMT 2007

# 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/ \
  $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/ \
  $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.


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

More information about the rsync mailing list