rsync download

Source-code releases

You can grab the latest source code and other related files in a variety of ways:

  • The latest version is linked on the main page.

  • A directory listing of these latest files and various historical release and diff files are available via this web page and via anonymous SSL rsync using this command:

    rsync-ssl rsync://

  • You can also get .zip and .tar.gz versions of the various git repo's release tags via the rsync GitHub releases page and the associated patches via the rsync-patches GitHub releases page. Keep in mind that these git-derived files do NOT come with the extra generated files that are included in the official release tar files.

  • You can browse the very latest source files, clone the source using git, or download a .zip file of the latest master branch from rsync's GitHub page.

  • The Samba git repo is also available, though it might lag behind the GitHub repo every now and then.

Once you have the source, read the file for details on some development libraries that you will need to build it.

The GPG Signing Key

The GPG signing key that is used to sign the release files is available from the public pgp key-server network. If you have automatic key-fetching enabled, just running a normal "gpg --verify" will grab my key automatically. Or, feel free to grab the gpp key for Wayne Davison manually.


Precompiled binaries are available in most modern OS distributions, so you should first check if you can install an rsync package via your standard package-install tools for your OS.

The GitHub Actions page has build events that each generate a few binary artifact zip files (just click through via the build's title to see them). The actions page is also linked via the various green build-status icons on the web pages here. These builds use the newest libraries, such as xxhash checksums and zstd compression, and are dynamically linked, so you may need to install some official library packages for your distribution. If you're curious how the build was done, you can look at the build rules in the "Workflow file" tab. See the file for some package name hints, though you can use the non-devel versions of the various lib packages and ignore the gcc/autoconf/awk packages.

There are also some binary tar files that are created in the process of testing rsync on various build machines. Most of these still have the latest compression and checksum features, but since I don't have root on any of the machines, I may have statically linked in a library that isn't installed on the host. Some of the tar files are from a particular release, and the "latest.tar.gz" file is periodically built from the very latest git source. Run "./rsync --version" on the extracted binary to see how recent it is.

There are also packages available from some 3rd-parties (note that we cannot vouch for 3rd parties, so use a source that you trust):

  • Cygwin is a Posix runtime for MS Windows that includes rsync among their many packages.

  • cwRsync is a native packaging of rsync for MS Windows (they appear to only provide paid releases, though).

Git source vs Release files

The release tar files come with a few generated files that are not checked in to git. These mainly include the man pages and the configure related files. To make use of the git-derived files you will need autoconf, autoheader, and a version of python3 that has the commonmark lib (OR cmarkgfm). If you have trouble with setting up the those required files, you can try running "./prepare-source fetchgen" to grab the very latest generated files that were created from the latest commit into the master branch.

Note: Since the source repository is a work in progress it may, at times, not compile or fail in various ways, though it is usually pretty good.

Source repository patches

There are also various patch files in the "rsync-patches" repository that represent either some work-in-progress features or features that are considered to be a little too fringe-interest for the main release. See the github link above for how to look around at what is available, or snag a release tar file. The maintainer like to put the rsync-patches dir into his rsync checkout as a directory named "patches" and has some helper scripts for how to use local git branches to test and update the diffs.