This proposal is for the addition of an option enabling fully custom copying behaviour in rsync, i.e- leveraging rsync primarily for detection of changes.

Custom copying behaviour is added using the --copy-command option, which takes a variable number of arguments in a similar same style to the `find` command's `-exec` option, terminated with a semi-colon.

For local copying, the special arguments `{src}` and `{dest}` can be used, and will be substituted for absolute paths for the source file and its destination respectively. For example:

    rsync --copy-command cp {src} {dest} \; "$source" "$destination"

To perform a completely pointless copy using `cp` to absolutely no advantage.

When dealing with a remote source, the copy command will receive the file's data as standard input. When dealing with a remote target, the copy command should produce file data as standard output.

Custom copying behaviour can be useful in a number of situations where copying tools have space-saving features, but do not have change detection or filtering options as flexible as `rsync` does.

Note: the custom behaviour is *only* triggered when rsync determines that a file's data should be copied, simple attribute, ownership and permission changes would occur as normal, without invoking the custom command. Likewise, directories etc. will be handled as normal. When a file is to be copied, rsync will skip its normally attempt to find differences with the target, and instead invoke the custom copy command, but will still synchronise any basic attributes (owner, permissions etc.).


For a useful example, on macOS there are some particular use cases. One invokes the `ditto` command to trigger compression of a file when transferred to an APFS or HFS+ target, which could be taken advantage of like so:

    rsync --copy-command ditto --hfsCompression {src} {dest} \; "$source" "$destination"

Since this enables a form of transparent compression, rsync should still see the copied file as identical to the original. Alternatively, the --noHfsCompression option could be used instead to ensure that compressed files are decompressed, even if the target would have been compatible.

Another useful macOS example is the use of cloning within an APFS volume, which will produce an instantaneous copy requiring no additional space, and can be used like so:

    rsync --copy-command cp -c {src} {dest} \; "$source" "$destination"

Again, since the copy is a clone it should be recognised as identical to the source by rsync on future passes.

In more complex cases, the copy command may produce a file that rsync cannot compare normally, for example, if the file is passed through `gz` or `xz`, in which case the use of checksums and size for comparison will need to be set accordingly.


While it would be nice to see cloning and HFS compression features added directly to rsync, this seemed like a much more flexible alternative, as it also potentially enables the use of various compression and/or encryption tools during transfers as well.