尽管主要是Windows用户，但我是rsync的忠实粉丝。现在，我不想争论rsync与任何其他工具的优点......这不是我的观点。
我发现在Windows上运行rsync的唯一方法是通过在Cygwin之上运行的版本，并且因为Cygwin存在Unicode问题，所以rsync也是如此。
是否有人熟悉rsync的工作原理，说明将rsync移植到本机Win32二进制文件是否存在任何真正的技术编程障碍？
或者也许是因为Windows用户从来没有足够的兴趣去关注它？
部分我问，因为我正在考虑尝试承担启动端口的任务，但我想确保在可能无法实现的原因方面没有我遗漏的东西。
答案 0 :(得分：5)
Windows锁定打开文件的方式可能会导致需要您挂钩Volume Shadowcopy服务的问题。
大约两年前，这位研究员将算法移植到C＃。我没有看过代码（或提供的二进制文件），但它可能是一个开始寻找或尝试联系的人。 http://www.russiantequila.com/wordpress/?p=8
答案 1 :(得分：1)
（免责声明：我保证，我不会谷歌自己，但谷歌分析把我带到了这里）
我将rsync移植到.net（sig11的链接是我的博客）。没有技术障碍，只有实际障碍。正如已经说过的，代码相当......密集。难以理解，完全缺乏评论。我很高兴让我的作品可用，但不幸的是，因为它是商业努力的一部分，它的形状并没有明显好转。
在很多情况下，我已经讨论过对协议进行逆向工程并进行与现有协议有线兼容的基础实现的想法，但是......使用起来更加清晰。我甚至已经开始了这样的维基，但是......正如你可以从那里缺少内容看到的那样，其他项目已经优先考虑。如果有人愿意和我一起工作，这可能是我需要开始的动力。该工具的概念很棒，它提供的功能也很棒，但它在* ix空间之外相当有限，并且绝对可以从api中受益。
wiki链接供参考：
http://www.russiantequila.com/wiki/index.php?title=Main_Page
答案 2 :(得分：0)
你见过这个：
http://www.itefix.no/i2/taxonomy/term/39
我已经使用了cwrsync而没有任何问题（以及通常的cygwin痛苦），但我没有任何unicode文件名的需要，所以我没有看到这个问题。
我真的不知道为什么没有原生的Win32端口，但我确实看了一会儿源，因为我在C＃中实现了类似的delta-copy系统。正如人们对杰出的* nix黑客的期望所预测的那样，消息来源主要是单字符变量名称和完全没有评论，这对于潜在的搬运工来说并不是很有帮助。 p>
答案 3 :(得分：0)
我一直在评估进行win32端口的努力。我不相信任何重大内容会阻止它，但来自rsync mailing list和另一个讨论的证据都指向严重依赖unix fork（）系统调用。使用线程似乎是win32的方法。
答案 4 :(得分：0)
我非常感谢rs-port到MS-Windows的端口，以便可以使用Visual Studio构建它。我随机地遇到各种协议错误，有点间歇性。我正在使用rsync将sw分发到大约200台机器的网格中，通常可以解决大约12个故障。我正在使用GCC 4.4.2和最新的cygwin来构建rsync v3.0.7。如果我可以试验一个不需要cygwin的版本，那对我很有用。这是因为网格中的机器已经运行了另一个基于cygwin的应用程序，它与我的版本不同。
花了一些时间在rsynv邮件列表上的意见似乎被分为MS-Windows上的协议错误的原因。有人说这是rsync中的一个错误，它无法执行干净的套接字关闭，这是一段时间前修复的错误。其他人说这是rsync中的基本协议错误，其中客户端没有告诉服务器它已完成，它只是关闭，导致MW-windows服务器在套接字上获得RST信号，这在Unix上不会发生