尽管我主要是 Windows 用户，但我是 rsync 的忠实粉丝。现在，我不想争论 rsync 与任何其他工具的优点……这不是我的意思。
我发现在 Windows 上运行 rsync 的唯一方法是通过构建为在 Cygwin 之上运行的版本，并且由于 Cygwin 存在 Unicode 问题，rsync 也是如此。
是否有人足够熟悉 rsync 的工作原理，可以说将 rsync 移植到本机 Win32 二进制文件是否存在任何真正的技术编程障碍？
还是可能是 Windows 用户从来没有足够的兴趣来关心移植它？
部分原因是因为我正在考虑尝试承担启动端口的任务，但我想确保我没有遗漏任何东西，因为它可能无法实现。
Windows 锁定打开文件的方式可能会导致需要您连接到卷影复制服务的问题。
大约两年前，这个家伙将算法移植到了 C#。我还没有查看代码（或提供的二进制文件），但它可能是开始寻找的地方或尝试联系的人。
http://www.russiantequila.com/wordpress/?p=8
我也一直在评估是否要进行 win32 移植。我不相信任何主要的东西会阻止它，但是来自rsync 邮件列表和另一个讨论的证据表明严重依赖于 unix fork() 系统调用。使用线程似乎是 win32 的必经之路。
（免责声明：我保证，我自己没有用谷歌搜索，但谷歌分析把我带到了这里）
我将 rsync 移植到 .net（sig11 的链接是我的博客）。没有技术障碍，只有实际障碍。如前所述，代码相当...密集。难以理解，完全没有评论。我很高兴能提供我的作品，但不幸的是，由于它是商业努力的一部分，它的状态并没有明显好转。
在很多情况下，我都搞乱了对协议进行逆向工程并进行与现有协议有线兼容的底层实现的想法，但是......使用起来更简洁。我什至为此创建了一个 wiki，但是……正如您从那里缺乏内容中看到的那样，其他项目已优先考虑。如果有人愿意在这方面与我合作，那可能是我前进的动力。
该工具的概念很棒，它提供的功能也很棒，但是它在 *ix 空间之外相当有限，并且绝对可以从 api 中受益。
wiki链接供参考：
你见过这个吗：
http://www.itefix.no/i2/taxonomy/term/39
我使用 cwrsync 没有任何问题（并且有很多常见的 cygwin 痛苦），但我不需要 unicode 文件名，所以我没有看到这个问题。
我真的不知道为什么没有本机 Win32 端口，但我确实查看了源代码，因为我在 C# 中实现了类似的 delta-copy 系统。正如人们对才华横溢的 *nix 黑客世界所期望的那样，来源主要是单字符变量名，并且完全没有评论，这并不是非常有用，而且可能会让潜在的搬运工相当反感。
我非常感谢 rsync 到 MS-Windows 的端口，以便可以使用 Visual Studio 构建它。我随机遇到各种协议错误，有些断断续续。我正在使用 rsync 将 sw 分发到大约 200 台机器的网格，并且通常会遇到十几个故障。我正在使用 GCC 4.4.2 和最新的 cygwin 来构建 rsync v3.0.7。如果我可以尝试一个不需要 cygwin 的版本，那将对我有很大帮助。这是因为网格中的机器已经运行了另一个基于 cygwin 的应用程序，该应用程序与我的应用程序版本不同。
Having spent some time on the rsynv mailing list opinion seems to be divided as to cause of protocol errors on MS-Windows. Some say it is a bug in rsync where it failed to do a clean socket shutdown, a bug that was fixed a while ago. Others say that it is a fundamental protocol error in rsync where the client does not tell the server that it is finished, it just shuts down, causing MW-windows servers to get a RST signal on the socket, something that does not happen on Unix.