Win32 rsync 端口的技术障碍
尽管我主要是 Windows 用户，但我还是 rsync 的忠实粉丝。 现在，我不想争论 rsync 与任何其他工具的优点......这不是我的观点。
我发现在 Windows 上运行 rsync 的唯一方法是通过在 Cygwin 之上运行的版本，并且由于 Cygwin 在 Unicode 方面存在问题，rsync 也存在问题。
是否有人足够熟悉 rsync 的工作原理，可以说将 rsync 移植到本机 Win32 二进制文件是否存在任何真正的技术编程障碍？
或者也许 Windows 用户从来没有足够的兴趣来关心将其移植？
我问这个问题的部分原因是我正在考虑尝试承担启动移植的任务，但我想确保我没有遗漏任何东西来解释为什么它不可能。
Despite primarily being a windows user, I am a huge fan of rsync. Now, I don't want to argue the virtues of rsync vs any other tool...this is not my point.
The only way I've ever found of running rsync on windows is via a version that is built to run on top of Cygwin, and as Cygwin has issues with Unicode, so does rsync.
Is anyone familiar enough with the workings of rsync to say if there are any real technical programming hurdles to porting rsync to a native Win32 binary?
Or is it maybe that there has just never been enough interest from windows users to care to port it over?
Partly I ask because I'm am considering trying to take on the task of starting a port, but I want to make sure there's not something I'm missing in terms of why it may not be possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Windows 锁定打开文件的方式可能会导致出现问题，要求您连接到卷影复制服务。
大约两年前，这个人将该算法移植到了 C# 上。 我还没有查看代码（或提供的二进制文件），但它可能是一个开始寻找的地方或尝试联系的人。
http://www.Russiantequila.com/wordpress/?p=8
The way that windows locks open files might cause an issue requiring you to hook into the Volume Shadowcopy Service.
About two years ago this fellow ported the algorithm to C#. I haven't taken a look at the code (or the provided binary), but it might be a place to start looking or someone to try contacting.
http://www.russiantequila.com/wordpress/?p=8
（免责声明：我保证，我自己不会用谷歌搜索，但谷歌分析把我带到了这里）
我经历了将rsync移植到.net（sig11的链接是我的博客）。 没有技术障碍，只有实际障碍。 正如已经说过的，代码相当......密集。 很难理解，而且完全缺乏评论。 我非常高兴能够提供我的作品，但不幸的是，由于它是商业努力的一部分，因此它的状态并没有明显好转。
我曾多次想过对协议进行逆向工程并进行与现有协议有线兼容的底层实现，但是......使用起来更干净一些。 我什至为此创建了一个维基，但是...正如您从缺乏内容中看到的那样，其他项目已优先考虑。 如果有人愿意在这方面与我合作，这可能是我继续前进的动力。
该工具的概念很棒，它提供的功能也很棒，但是它在 *ix 空间之外相当有限，并且绝对可以从 api 中受益。
供参考的 wiki 链接：
http://www.Russiantequila.com/wiki/index .php?title=Main_Page
(disclaimer: i promise, i don't google myself, but google analytics brought me here)
i went through porting rsync to .net (sig11's link is my blog). there are no technical hurdles, just practical ones. as was already said, the code is rather... dense. difficult to follow, and complete lack of comments. i'm more than happy to make my work available, but unfortunately, since it was part of a commercial effort, it's not in significantly better shape.
i have, on a number of occasions, messed around with the idea of reverse-engineering the protocol and doing a ground-up implementation that's wire-compatible with the existing one, but ... a bit cleaner to work with. i've even started a wiki to that effect, but... as you can see from the lack of contents there, other item have taken priority. if anyone would like to work with me on this, that may be the impetus i need to get going.
the concept of the tool is great, as is the functionality it offers, however it's rather limited outside the *ix space, and could definitely benefit from an api.
wiki link for reference:
http://www.russiantequila.com/wiki/index.php?title=Main_Page
我也一直在评估进行 win32 移植的努力。 我不相信任何重大的事情会阻止它，但是来自 rsync 邮件列表 和另一个讨论指出了对 unix fork() 系统调用的严重依赖。 使用线程似乎是 win32 的最佳选择。
线程与分叉讨论
I've been evaluating an effort to undertake a win32 port as well. I don't believe anything major would block it, but evidence from both the rsync mailing list and another discussion points to a heavy reliance on unix fork() system calls. Using threads appears the way to go for win32.
Threads vs. Fork discussion
我真的很感激将 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 上不会发生。
I would really appreciate a port of rsync to MS-Windows such that it can be built using Visual Studio. I am encountering various protocol errors at random, somewhat intermittently. I am using rsync to distribute sw to a grid of around 200 machines and typically get around a a dozen failures. I am using GCC 4.4.2 and the latest cygwin to build rsync v3.0.7. It would help me alot if I could experiment with a version that does not require cygwin. This is because the machines in the grid already have another cygwin-based app running that is a different version to the one I have.
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.
您是否看到过：
http://www.itefix.no/i2/taxonomy/term /39
我使用cwrsync没有任何问题（并且有很多常见的cygwin痛苦），但我不需要unicode文件名，所以我没有看到这个问题。
我真的不知道为什么没有本机 Win32 端口，但我不久前确实查看了源代码，因为我在 C# 中实现了类似的增量复制系统。 正如人们对出色的 *nix 黑客世界所期望的那样，其来源主要是单字符变量名，并且完全没有注释，这并不是很有帮助，而且可能会让潜在的搬运工感到相当反感。
Have you seen this:
http://www.itefix.no/i2/taxonomy/term/39
I have used cwrsync without any problem (and with the much of the usual cygwin misery), but I haven't had any need for unicode filenames, so I've not seen that problem.
I don't really know why there isn't a native Win32 port, but I did look at the source a while back because I implemented a similar delta-copy system in C#. As one would expect from the world of brilliant *nix hackers, the source is largely single-character variable names and a total absence of comments, which isn't terrible helpful and might be rather off-putting to would-be porters.