Wayne Davison

Every file name mentioned is relative to the top of the transfer. Given a destination dir of `/tmp` the receiving side's deletions are always relative to that.

I'll note that tweaking `.github/workflows/build.yml` to include `coreutils` on the `brew install` line should hopefully be enough to fix the test error on macOS.

As you noted, if you instead run `sudo rsync -a source/* destination` it won't fiddle the dir since it's sending only files, not the parent dir. This assumes that there...

I believe I'll merge it for the next release.

It is just assumed that you don't run such a command at the moment. I'll note that the older, `--remove-sent-files` would avoid this particular deletion since it only removes files...

I finally came up with a simple solution for this and checked it into git. Given the distributed nature of the sender & receiver processes, I had been thinking about...

Rsync is doing checksum searching, which can be slow on a large file. You can use `--whole-file` (`-W`) to turn off the rsync algorithm when transferring large files (the faster...

Using `--whole-file` would work like your manually removing files you want to update as long as the mtime and/or size don't match. It avoids all the checksum record matching. The...

In the future I will probably change the sender to segment really large files into chunks so the transfer will be as efficient as if the large file had been...

Please try out the latest code (with a fresh configure run). It will now default to not using the asm version of the rolling-checksum code. If you want to try...