rsync @3.1.1: Incorrect behaviour of --append-verify (and --partial) options

[ksze (Kal Sze)]

OS X 10.11.1 El Capitan

rsync version: 3.1.1

I seem to have discovered a nasty bug with the --append-verify (and --partial) options of rsync.

As far as I can understand, the whole point of --append-verify is that in case of interruption, rsync will leave the destination file in its current state so that it can be resumed at a later point.

Consider, for example:

• source volume: "/Volume/DyingHDD"
• destination volume: "/Volume/NewHDD"

Suppose I have a 2 GB file "/Volume/DyingHDD/00027.MTS" and my DyingHDD is really dying: its read speed has degraded to around 5 MB/s and it's so unstable that it can't read 10 GB without suddenly going offline (OS X would think that it has not been ejected cleanly).

So I try to salvage whatever is on DyingHDD by doing "rsync -av --append-verify --timeout=60 /Volume/DyingHDD/ /Volume/NewHDD/". Now, a few hundred MBs into 00027.MTS, DyingHDD suddenly disappears. I would expect rsync to leave "/Volume/NewHDD/00027.MTS" at the few hundred MB mark and quit.

But that's not what happened. Instead, rsync proceeded to fill "/Volume/NewHDD/00027.MTS" all the way to 2 GB at the full speed of NewHDD (about 150 MB/s), and leave its timestamp at the current system time.

Output of rsync:

00027.MTS
  2,125,627,392 100%   29.94MB/s    0:01:07 (xfr#11, ir-chk=1083/66263)

So the next time I call "rsync -av --append-verify --timeout=60 /Volume/DyingHDD/ /Volume/NewHDD/", rsync just skips over 00027.MTS.

--partial has a similar behaviour

I somewhat doubt it's a general bug in rsync exists in all platforms. All of the Linux people that I have spoken to say that --append-verify does leave the file in its partial state on Linux.

[ryandesign (Ryan Carsten Schmidt)]

Even if it is a Mac-specific bug, it does not sound like a MacPorts-specific bug, so it should be reported to the developers of rsync for resolution.