I have read and understand why --inplace and --sparse can't normally coexist. However, those reasons don't seem to apply to a case where --whole-file is in play. Consider the use case of a 10GB VM image with 512MB of sparseness. On the source the file uses 9.5GB of storage. But on the target, rsync forces me to choose between 10GB of permanent storage or 9.5GB of permanent storage + another 9.5GB of temporary storage while the file is updated. If --whole-file --sparse --inplace were all in play then rsync could write out an entirely new sparse sparse file over the existing file without requiring any temporary storage space. IOW, I would like 'rsync --whole-file --sparse --inplace srcfile tgtfile' to be equivalent to 'rm tgtfile ; rsync --sparse srcfile tgtfile' but with rsync's --inplace handling of the new file rather than making a .tgtfile.rsync.randomstring file.
What is the technical limitation exactly? Different transfer algorithms? This comes from OLDNEWS: - Reject the combination of --inplace and --sparse since the sparse-output algorithm doesn't work when overwriting existing data. The --inplace --sparse combination was rejected since https://git.samba.org/rsync.git/?p=rsync.git;a=commitdiff;h=cfce9f6dc353a013ab8d07c20a392aeaf6cab5ea For a local full system backup, I would prefer a best-effort transfer where 99% of all files are copied with --inplace (such that btrfs COW still works) while that single sparse Docker file of 100G (in reality 0 bytes) does not eat all space (apply --sparse). Would that be a possibility? Maybe a --sparse=try option besides --sparse[=always]?
There was not a way to punch holes in existing files in the past, but that has been fixes in modern OSes and rsync now takes advantage of it.