尽管主要是Windows用户，但我还是rsync的忠实拥护者。现在，我不想争辩rsync与任何其他工具的优点……这不是我的意思。
我发现在Windows上运行rsync的唯一方法是通过一个在Cygwin之上运行的版本，并且Cygwin的Unicode存在问题，rsync也是如此。
是否有人熟悉rsync的工作原理，以说是否存在将rsync移植到本地Win32二进制文件的真正技术编程障碍？
或者也许Windows用户从未有过足够的兴趣来移植它？
部分原因是因为我正在考虑尝试启动端口的任务，但我想确保就为什么不可能实现这一点我没有缺少。
Windows锁定打开文件的方式可能会导致出现问题，要求您挂接到Volume Shadowcopy Service。
[大约两年前，这位研究员将算法移植到C＃。我没有看过代码（或提供的二进制文件），但是它可能是一个开始寻找或尝试联系的地方。http://www.russiantequila.com/wordpress/?p=8
（免责声明：我保证，我不会用谷歌搜索自己，但是谷歌分析将我带到了这里）
我通过将rsync移植到.net（sig11的链接是我的博客）。没有技术上的障碍，只有实际的障碍。就像已经说过的那样，代码相当...密集。难以遵循，完全缺乏评论。我很乐意提供我的作品，但是不幸的是，由于这是商业活动的一部分，因此它的状态并没有明显改善。
在很多情况下，我对协议的反向工程和进行与现有协议有线兼容的基础实现的想法感到困惑，但是……使用起来却更加干净。为此，我什至已经启动了Wiki，但是...正如您从那里缺少内容所看到的那样，其他项已被优先处理。如果有人想在这方面与我合作，那可能就是我需要继续前进的动力。
该工具的概念很棒，它提供的功能也不错，但是它在* ix空间之外相当有限，肯定可以从api中受益。
Wiki参考链接：
http://www.russiantequila.com/wiki/index.php?title=Main_Page
您看过这个吗：
http://www.itefix.no/i2/taxonomy/term/39
我使用cwrsync时没有任何问题（并且有很多常见的cygwin痛苦），但是我不需要Unicode文件名，所以我没有看到这个问题。
我真的不知道为什么没有本机的Win32端口，但是我确实回想了一下源代码，因为我在C＃中实现了类似的增量复制系统。正如人们从杰出的* nix黑客世界中所期望的那样，来源主要是单字符变量名称，并且完全没有注释，这并不是很有用，并且可能对潜在的搬运工不利。
我也一直在评估采用Win32端口的努力。我不相信任何专业都会阻止它，但是rsync mailing list和其他讨论的证据都表明严重依赖unix fork（）系统调用。使用线程似乎是win32的使用方法。
我非常感谢rsync到MS-Windows的端口，以便可以使用Visual Studio构建它。我偶尔会间歇性地遇到各种协议错误。我正在使用rsync将sw分发到大约200台计算机的网格中，通常会遇到十几个故障。我正在使用GCC 4.4.2和最新的cygwin构建rsync v3.0.7。如果我可以尝试不需要cygwin的版本，将会对我有很大帮助。这是因为网格中的计算机已经在运行另一个基于cygwin的应用程序，该应用程序与我的应用程序版本不同。
花了一些时间在rsynv邮件列表上的意见似乎因MS-Windows上协议错误的原因而存在分歧。有人说这是rsync中的一个错误，它无法执行干净的套接字关闭操作，该错误已在不久前修复。其他人则说这是rsync中的一个基本协议错误，客户端没有告诉服务器它已经完成，它只是关闭了，导致MW-windows服务器在套接字上收到RST信号，这在Unix上不会发生。