--sparse + --inplace = broken files

[lilydjwg]

1. Get some files, e.g. a git repo, on a remote machine
2. rsync it to a local place with rsync -avi --sparse --inplace host:path dest
3. Change some files, e.g. switching branches
4. rsync again with the same arguments. rsync again and again.

The result is never-completed, failed verification errors, like this:

receiving incremental file list
>f..t...... test/.git/index
WARNING: test/.git/index failed verification -- update retained (will try again).
>f..t...... test/.git/hooks/pre-rebase.sample
WARNING: test/.git/hooks/pre-rebase.sample failed verification -- update retained (will try again).
>f..t...... test/.git/hooks/update.sample
WARNING: test/.git/hooks/update.sample failed verification -- update retained (will try again).
>f..t...... test/.git/logs/HEAD
WARNING: test/.git/logs/HEAD failed verification -- update retained (will try again).
>f..t...... test/.git/index
ERROR: test/.git/index failed verification -- update retained.
>f..t...... test/.git/hooks/pre-rebase.sample
ERROR: test/.git/hooks/pre-rebase.sample failed verification -- update retained.
>f..t...... test/.git/hooks/update.sample
ERROR: test/.git/hooks/update.sample failed verification -- update retained.
>f..t...... test/.git/logs/HEAD
ERROR: test/.git/logs/HEAD failed verification -- update retained.

The failed files have a lot of zero bytes at the beginning or end. I didn't check all of them and there may be other cases.

The filesystem on both sides doesn't matter (tried btrfs and tmpfs). I didn't reproduce it with a local transfer.

All involved systems are recent Arch boxes and rsync version is 3.2.3-1.

[jigpu]

Experiencing the same issue when sending from an Arch system (rsync 3.2.3) to a Debian-based system (rsync 3.1.3).

[jigpu]

Did some more poking and found that the issue seems to exist even in commit f3873b3 which introduced the --sparse --inplace support.

I've attached a script which will consistently reproduce the issue: testcase.sh.txt

[WayneD]

Rsync 3.1.3 is too old for that option combo. You need at least 3.2.0:

https://download.samba.org/pub/rsync/NEWS#3.2.0

I couldn't get your test case to fail with a newer rsync (just an older one).

[lilydjwg]

The test script fails with exit code 1 every time on Arch Linux and its rsync 3.2.3-3.

[jigpu]

@WayneD what distro are you testing on? I'm also on Arch and get 100% testcase failure on any version I try (master branch, 3.2.3-3, or the initial commit). I'm going to set up a couple of fresh VMs to see if I can find any distro dependence...

Thanks for the heads-up on 3.1.3 being incompatible, BTW.

[jigpu]

The testcase script has failed in each of the VMs that I've set up:

• Debian 10.9
• Ubuntu 20.04
• Ubuntu 21.04
• openSUSE Leap 15.3
• Fedora 34
• Solus 4.2

Each distro was fully updated prior to running the testcase against the master branch. I've attached a script which I've used to clone, build, and test on each system: rsync-test-setup.sh.txt

[WayneD]

I've tracked down the issue to a spurious truncate due to the whole_file var being -1. You should be able to avoid the issue in various recent rsync versions by forcing --no-whole-file (aka --no-W) on both sides (e.g. --no-W -M--no-W). I'll have the git version fixed soon.

[WayneD]

Fixed in git. Thanks for the test-case help!

[smemsh]

@WayneD to clarify, does this disable delta xfer algorithm on all files in the transfer? This would require users to keep track of sparse files and do separate rsync runs, to get efficient transfers of their non-sparse files

[WayneD]

You've confused --whole-file with --no-whole-file. Though many people would get better transfer speeds these days with --whole-file (no delta xfer), the above explicit setting of --no-whole-file ensures that the already-in-effect default transfer option gets properly honored in all the checks on older rsyncs. This is due to the whole_file var's 3 states: default, requested-on & requested-off. The value got left as "default" which most of the code treated as "off", but the sparse code treated it as "on". While the bug can also be avoided using --whole-file (-W), my recommendation of explicitly specifying --no-W (and making sure that the remote side gets that option too) makes it work without any change in behavior from the default.