Technical Hurdles for Win32 rsync port

Question

Mimo że przede wszystkim jestem użytkownikiem systemu Windows, jestem wielkim fanem rsync. Teraz nie chcę dyskutować o zaletach rsync w porównaniu z jakimkolwiek innym narzędziem ... nie o to mi chodzi.

Jedyny sposób, jaki kiedykolwiek znalazłem na uruchamianie rsync w systemie Windows, to wersja, która jest stworzona do uruchamiania na Cygwin, a ponieważ Cygwin ma problemy z Unicode, tak samo robi rsync.

Czy ktoś jest wystarczająco znany z działaniem rsync, aby powiedzieć, czy istnieją jakiekolwiek techniczne przeszkody w programowaniu do przeniesienia rsync do natywnej binarki Win32?

A może po prostu nie było wystarczająco dużego zainteresowania użytkowników systemu Windows, aby go przenieść?

Częściowo pytam, ponieważ zastanawiam się nad podjęciem próby uruchomienia portu, ale chcę się upewnić, że nie ma czegoś, czego mi brakuje, jeśli chodzi o przyczyny, dla których nie jest to możliwe.

Answer 1

Sposób, w jaki system Windows blokuje otwarte pliki, może powodować problem wymagający podpięcia się do usługi Volume Shadowcopy.

Około dwa lata temu ten człowiek przeprogramował algorytm na C#. Nie przyjrzałem się kodowi (lub dostarczonemu plikowi binarnemu), ale może to być miejsce do rozpoczęcia wyszukiwania lub ktoś, kto spróbuje się skontaktować.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

Widzieliście to:

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

Użyłem cwrsync bez problemu (i ze znacznie od zwykłej cygwin nędzy), ale nie miałem żadnej potrzeby dla Unicode nazwy plików, więc nie widziałem tego problemu.

Naprawdę nie wiem, dlaczego nie ma natywnego portu Win32, ale spojrzałem na źródło jakiś czas temu, ponieważ zaimplementowałem podobny system delta-copy w języku C#. Jak można oczekiwać od świata genialnych hakerów * nix, źródłem są w dużej mierze jednoliterowe nazwy zmiennych i całkowity brak komentarzy, co nie jest strasznie pomocne i może być raczej niepotrzebne dla przyszłych porterów.

Answer 3

Podejmowałem także próbę wykonania portu win32. Nie wierzę, że coś poważnego mogłoby go blokować, ale dowody zarówno z rsync mailing list i kolejnej dyskusji wskazują na duże uzależnienie od wywołań systemu UNIX fork(). Używanie wątków jest sposobem na przejście na win32.

Threads vs. Fork discussion

Answer 4

(disclaimer: Obiecuję, nie google siebie, ale Google Analytics przyniósł mi tutaj)

poszedłem poprzez przenoszenie rsync do .net (Sig11 za link jest mój blog). nie ma technicznych przeszkód, tylko praktyczne. jak już powiedziano, kod jest raczej ... gęsty. trudne do naśladowania i zupełny brak komentarzy. Cieszę się, że mogę udostępnić moją pracę, ale niestety, ponieważ była to część wysiłku komercyjnego, nie jest ona w znacznie lepszej formie.

Mam, przy wielu okazjach, pomieszany z ideą inżynierii wstecznej protokół i wykonanie zminiaturyzowanej implementacji, która jest zgodna z istniejącą, ale ... nieco czystsza do pracy z . W tym celu zacząłem nawet wiki, ale ... jak widać z braku treści, inne przedmioty stały się priorytetem. jeśli ktoś chciałby ze mną współpracować, to może być bodziec, który muszę podjąć.

Koncepcja narzędzia jest świetna, podobnie jak funkcjonalność, którą oferuje, jednak jest ograniczona poza przestrzenią * ix i zdecydowanie może czerpać korzyści z interfejsu API.

Link wiki dla odniesienia:

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

Answer 5

będę naprawdę wdzięczny do portu rsync MS-Windows tak, że może on być zbudowany przy użyciu programu Visual Studio. Napotykam różne przypadki błędów protokołów, w pewnym sensie sporadycznie. Używam rsync do dystrybucji sw do siatki około 200 maszyn i zazwyczaj otrzymuję około dwunastu błędów. Używam GCC 4.4.2 i najnowszego cygwin do zbudowania rsync v3.0.7. Pomogłoby mi to, gdybym mógł poeksperymentować z wersją, która nie wymaga cygwin. Dzieje się tak dlatego, że na komputerach w sieci jest już uruchomiona inna aplikacja działająca w oparciu o cygwin, która jest inną wersją niż ta, którą mam.

Po spędzeniu pewnego czasu na liście dyskusyjnej rsynv opinia wydaje się być podzielona co do przyczyny błędów protokołów w MS-Windows. Niektórzy twierdzą, że jest to błąd w rsync, w którym nie udało się zrobić czystego wyłączenia gniazda, błędu, który został naprawiony jakiś czas temu. Inni mówią, że jest to podstawowy błąd protokołu w rsync, w którym klient nie informuje serwera, że ​​jest gotowy, po prostu się wyłącza, powodując, że serwery MW-MW uzyskują sygnał RST na gnieździe, co nie ma miejsca w systemie Unix .