Yes and no. By default, rsync primarily relies on the file size and modification timestamps to determine whether a particular file needs to be (re-)synchronized. The -c/--checksum option in rsync runs checksums during the initial scan of both ends, instead of relying on file size and timestamp.
However, note that these checksums are only computed _prior_ to performing any data transfers. So using -c cannot serve as a file integrity check after the transfer has been performed. This is why, whenever I want to backup or archive stuff using rsync, I run the same rsync command _twice_, the first time using 'rsync -av', and then the second time using 'rsync -avc'. If the checksumming the second time doesn't result in any data being transferred, then you can essentially treat the second rsync as a file integrity check. P.S.: One other downside to using rsync's -c option is that it uses a 128-bit MD4 checksum, not MD5 or SHA. -- Jason Liu On Fri, Aug 29, 2025 at 1:55 PM Nils Breunese <br...@macports.org> wrote: > Ryan Carsten Schmidt <ryandes...@macports.org> wrote: > > > On Aug 29, 2025, at 11:01, Dave Allured - NOAA Affiliate wrote: > > > >> What is the problem with just going back to rsync and hosting the > uncompressed port tree? Then only the changed files would be downloaded > for port sync. You could also offer a complete tarball available as an > alternative, for new installs and full rebuilds. I feel like I am missing > something here. > > > > We switched to using a tarball so that its integrity could be verified > with a signature. > > > > > https://github.com/macports/macports-base/commit/476e4e15ff52ed1582cafa5d4be0476a6c05a5c1 > > AFAIK rsync can already do file-level integrity checksum checks, so maybe > there is no need for this? > > Nils.
