#49657: Incorrect behaviour of --append-verify (and --partial) options --------------------------+-------------------------------- Reporter: swordangel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: rsync --------------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/49657> MacPorts <https://www.macports.org/> Ports system for OS X