尽管主要是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

回答

你见过这个吗：

http://www.itefix.no/i2/taxonomy/term/39

我使用cwrsync时没有任何问题(并且有很多常见的cygwin痛苦)，但是我并不需要unicode文件名，因此我没有看到这个问题。

我真的不知道为什么没有本机的Win32端口，但是我确实看过源代码，因为我在C＃中实现了类似的增量复制系统。正如人们从杰出的* nix黑客世界中所期望的那样，来源主要是单字符变量名称，并且完全没有注释，这并不是很有用，并且可能对潜在的搬运工不利。

回答

我一直在评估一项努力，以承担一个Win32端口。我不相信任何专业都会阻止它，但是rsync邮件列表和另一个讨论中的证据都表明严重依赖unix fork()系统调用。使用线程似乎是win32的必经之路。

线程与Fork讨论

回答

(免责声明：我保证，我不会用谷歌搜索自己，但是谷歌分析将我带到了这里)

我经历了将rsync移植到.net的问题(sig11的链接是我的博客)。没有技术上的障碍，只有实际的障碍。就像已经说过的那样，代码相当...密集。难以遵循，完全缺乏评论。我很乐意提供我的作品，但不幸的是，由于这是商业活动的一部分，因此它的状态没有明显改善。

在很多情况下，我都对反向工程协议的想法感到困惑，并进行了与现有协议有线兼容的基础实现，但是……使用起来更加干净。为此，我什至已经启动了Wiki，但是...正如我们从那里缺少内容所看到的那样，其他项已被优先处理。如果有人想在这方面与我合作，那可能就是我需要继续前进的动力。

该工具的概念很棒，它提供的功能也很棒，但是它在* ix空间之外相当有限，并且肯定可以从api中受益。

Wiki链接供参考：

http://www.russiantequila.com/wiki/index.php?title=Main_Page

回答

我非常感谢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上不会发生。