Technische Hürden für den Win32-rsync-Port

Question

Obwohl ich hauptsächlich Windows-Benutzer bin, bin ich ein großer Fan von rsync.Nun möchte ich nicht über die Vorzüge von rsync im Vergleich zu anderen Tools streiten ... das ist nicht mein Punkt.

Die einzige Möglichkeit, rsync unter Windows auszuführen, die ich jemals gefunden habe, ist eine Version, die für die Ausführung auf Cygwin entwickelt wurde, und da Cygwin Probleme mit Unicode hat, hat auch rsync Probleme.

Ist jemand mit der Funktionsweise von rsync ausreichend vertraut, um sagen zu können, ob es echte technische Programmierhürden bei der Portierung von rsync auf eine native Win32-Binärdatei gibt?

Oder liegt es vielleicht daran, dass das Interesse von Windows-Benutzern nie groß genug war, um sich für eine Portierung zu interessieren?

Zum Teil frage ich, weil ich darüber nachdenke, die Aufgabe zu übernehmen, einen Port zu starten, aber ich möchte sicherstellen, dass mir nichts entgeht, was die Gründe dafür angeht, warum dies möglicherweise nicht möglich ist.

Answer 1

Die Art und Weise, wie Windows geöffnete Dateien sperrt, kann zu einem Problem führen, das eine Verbindung zum Volume Shadowcopy-Dienst erforderlich macht.

Vor etwa zwei Jahren hat dieser Kerl den Algorithmus auf C# portiert.Ich habe mir den Code (oder die bereitgestellte Binärdatei) nicht angesehen, aber es könnte ein Ort sein, an dem man mit der Suche beginnen oder jemanden finden kann, den man kontaktieren kann.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

(Haftungsausschluss:Ich verspreche, ich google nicht selbst, aber Google Analytics hat mich hierher gebracht)

Ich habe rsync auf .net portiert (der Link von sig11 ist mein Blog).Es gibt keine technischen Hürden, sondern nur praktische.Wie schon gesagt, der Code ist eher...dicht.schwer zu verstehen und völliges Fehlen von Kommentaren.Ich stelle meine Arbeit gerne zur Verfügung, aber da sie Teil einer kommerziellen Aktion war, ist sie leider nicht in einem wesentlich besseren Zustand.

Ich habe mehrfach mit der Idee herumgespielt, das Protokoll zurückzuentwickeln und eine Grundimplementierung durchzuführen, die kabelkompatibel mit der bestehenden ist, aber ...etwas sauberer zum Arbeiten.Ich habe sogar ein Wiki zu diesem Zweck gestartet, aber...Wie Sie am Mangel an Inhalten erkennen können, haben andere Elemente Vorrang.Wenn jemand mit mir daran zusammenarbeiten möchte, könnte das der Anstoß sein, den ich brauche, um loszulegen.

Das Konzept des Tools ist großartig, ebenso wie die Funktionalität, die es bietet, allerdings ist es außerhalb des *ix-Bereichs eher begrenzt und könnte definitiv von einer API profitieren.

Wiki-Link als Referenz:

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

Answer 3

Hast du das gesehen:

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

Ich habe cwrsync ohne Probleme verwendet (und mit dem üblichen Cygwin-Missbrauch), aber ich hatte keinen Bedarf an Unicode-Dateinamen, daher ist mir dieses Problem nicht aufgefallen.

Ich weiß nicht wirklich, warum es keinen nativen Win32-Port gibt, aber ich habe mir vor einiger Zeit die Quelle angesehen, weil ich ein ähnliches Delta-Copy-System in C# implementiert habe.Wie man es in der Welt der brillanten *nix-Hacker erwarten würde, besteht die Quelle größtenteils aus einstelligen Variablennamen und einem völligen Fehlen von Kommentaren, was nicht besonders hilfreich ist und potenzielle Portierer eher abschrecken könnte.

Answer 4

Ich habe darüber nachgedacht, auch eine Win32-Portierung durchzuführen.Ich glaube nicht, dass irgendetwas Großes es blockieren würde, aber Beweise von beiden rsync-Mailingliste und eine andere Diskussion weist auf eine starke Abhängigkeit von Unix-Fork()-Systemaufrufen hin.Die Verwendung von Threads scheint für Win32 der richtige Weg zu sein.

Threads vs.Fork-Diskussion

Answer 5

Ich würde mich sehr über eine Portierung von rsync auf MS-Windows freuen, sodass es mit Visual Studio erstellt werden kann.Ich stoße zufällig und zeitweise auf verschiedene Protokollfehler.Ich verwende rsync, um SW an ein Raster von etwa 200 Maschinen zu verteilen, und erhalte normalerweise etwa ein Dutzend Fehler.Ich verwende GCC 4.4.2 und das neueste Cygwin, um rsync v3.0.7 zu erstellen.Es würde mir sehr helfen, wenn ich mit einer Version experimentieren könnte, die kein Cygwin erfordert.Das liegt daran, dass auf den Maschinen im Grid bereits eine andere Cygwin-basierte App läuft, die eine andere Version als die hat, die ich habe.

Nachdem ich einige Zeit auf der rsynv-Mailingliste verbracht habe, scheinen die Meinungen über die Ursache von Protokollfehlern unter MS-Windows geteilt zu sein.Einige sagen, es handele sich um einen Fehler in rsync, bei dem das saubere Herunterfahren des Sockets fehlschlug, ein Fehler, der vor einiger Zeit behoben wurde.Andere sagen, es handele sich um einen grundlegenden Protokollfehler in rsync, bei dem der Client dem Server nicht mitteilt, dass er fertig ist, sondern einfach herunterfährt, was dazu führt, dass MW-Windows-Server ein RST-Signal am Socket empfangen, was unter Unix nicht der Fall ist .