Win32 rsync端口的技術障礙

Question

儘管主要是Windows用戶，但我是rsync的忠實粉絲。現在，我不想爭論rsync與任何其他工具的優點......這不是我的觀點。

我發現在Windows上運行rsync的唯一方法是通過一個構建在Cygwin上運行的版本，並且由於Cygwin存在Unicode問題，rsync也是如此。

是否有人熟悉rsync的工作方式來說明是否有任何真正的技術編程障礙將rsync移植到本機Win32二進制文件？

或者，它可能是從來沒有足夠的興趣，從Windows用戶關心移植它？

部分我問，因爲我正在考慮嘗試開始一個端口的任務，但我想確保沒有什麼我錯過了爲什麼它可能不可能。

Answer 1

窗口鎖定打開文件的方式可能會導致需要掛鉤到卷影拷貝服務的問題。

大約兩年前，這位研究員將算法移植到了C＃中。我沒有看過代碼（或提供的二進制文件），但它可能是一個開始查找或嘗試聯繫人的地方。
http://www.russiantequila.com/wordpress/?p=8

Answer 2

你見過這樣的：

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

我用cwrsync沒有任何問題（而且與許多常用的cygwin的痛苦），但我還沒有得到任何需要的Unicode文件名，所以我沒有看到這個問題。

我真的不知道爲什麼沒有原生的Win32端口，但我之前看了一下源代碼，因爲我在C＃中實現了類似的增量複製系統。正如人們所期望的來自輝煌的* nix黑客世界，源代碼很大程度上是單字符變量名稱，並且完全沒有評論，這不是可怕的幫助，並且可能會對願意的搬運工非常不利。

Answer 3

我一直在評估努力承擔win32端口。我不相信任何重大的東西都會阻止它，但是來自rsync mailing list和另一個討論的證據都表明嚴重依賴於unix fork（）系統調用。使用線程似乎是win32的方式。

Threads vs. Fork discussion

Answer 4

（免責聲明：我保證，我不會谷歌自己，但Google Analytics（分析）把我帶到這裏）

通過我的rsync移植到.NET（SIG11的鏈接是我的博客）去了。沒有技術障礙，只有實際的障礙。正如已經說過的那樣，代碼相當密集。難以遵循，並且完全缺乏評論。我很高興能夠提供我的工作，但不幸的是，由於它是商業努力的一部分，所以它的形狀並不明顯。

我在很多場合都混淆了對協議進行逆向工程的想法，並且做了一個與現有協議有線兼容的開創性實現，但是...更清潔一點。我甚至已經開始了一個wiki，但是......正如你可以從內容不足那裏看到的，其他項目已經被優先考慮。如果有人願意和我一起工作，那可能是我需要走的動力。

該工具的概念很好，它提供的功能也是如此，但它在* ix空間之外相當有限，並且肯定可以從api中受益。

維基鏈接以供參考：

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

Answer 5

我會很感激的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上不會發生。