RSync und Windows, wie funktioniert das?

[Memnarch]

Hi,
RSync ist nun eigentlich ein Tool der Linux Welt, um 2 Speicherorte zu synchronisieren. Und zwar mit so wenig Traffic wie möglich. Dazu wird soweit möglich ein Block-LevelCopy angewand, basierend auf einem lokal erstellten binarydiff.

Soweit habe ich auch kein verständniss problem. Mit einer speziellen sache jedoch habe ich eines:
RSync gibt es auch für windows. Dabei muss ich lediglich auf einem von 2 Windows-PCs RSync haben und dort aufrufen.
Wenn RSync Bytes

innerhalb einer datei modifiziert
Hinte dran hängt

kann ich dem ganzen konzept auch noch folgen(man könnte hier für eine native implementierung z.B. Filestreams verwenden). Was aber wen ich mittendrin ein Byte EINFÜGE, womit sich der restliche Inhalt um 1 Byte verschiebt? Die kalkulation des Diffs ist nicht das Problem, vielmehr, wie stellt RSync hier einen optimalen Transfer zur verfügung? Die Datei muss um 1 Byte in der länge erweitert werden, und dann der gesamte Inhalt der Datei ab dem insert um ein Byte nach hinten geschoben werden um das Byte einfügen zu können. Ich kann mir nicht vorstellen, dass Windows da irgendwas unterstützt?(RoboCopy von MS kopiert z.B. immer ganze dateien)

Wie kommuniziert RSync den dann auf Windows clients?(Unc/SSH stehen soweit ich weiß zur verfügung)


Grüße
Memnarch

[Namenloser]

Es gibt ja nicht so viele Dateitypen, wo das passiert – eigentlich nur bei Textdateien/Dokumenten, und die sind ja meistens nicht so groß... jeder lokale Texteditor hat ja dasselbe Problem.

Bevor ich mich frage, was für Magie RSync da betreibt, würd ich erst mal gucken, ob überhaupt Magie betrieben wird, z.B. mit einem Packet Sniffer wie Wireshark (oder im Source Code nachschauen). Ich weiß es nicht, aber ich tippe mal darauf, dass RSync einfach ganz naiv ab der geänderten Stelle den Inhalt bis zum Ende neu schreibt.

[Sir Rufo]

Wikipedia http://de.m.wikipedia.org/wiki/Rsync
Linux-Magazin http://www.linux-magazin.de/Ausgaben...ycling-Meister

Das sollte das Prinzip (rollierende Prüfsumme) verdeutlichen :)

[Memnarch]

Zitat:

Zitat von Sir Rufo (Beitrag 1265116)

Wikipedia http://de.m.wikipedia.org/wiki/Rsync
Linux-Magazin http://www.linux-magazin.de/Ausgaben...ycling-Meister

Das sollte das Prinzip (rollierende Prüfsumme) verdeutlichen :)

Ja aber genau diese stelle hier macht mich doch stutzig(und darum geht es mir hier):

Zitat:

Der Rsync-Empfänger teilt die vorhandene Zieldatei in Blöcke fester Größe auf (je nach Dateigröße), berechnet für jeden Block eine Prüfsumme und teilt nur diese Summen dem Sender mit. Der durchforstet seine eigene Datei und ermittelt, welchen der Blöcke er ebenfalls hat. Am Ende sendet er alle fehlenden Stellen zusammen mit Hinweisen, welche Blöcke der Empfänger an welcher Stelle wiederverwenden muss.

Unter windows gibt es KEINEN gegenpart. Da ist niemand der mit dem Client quatschen kann. Auf Linux mag RSync ja quasibestandteil sein, womit davon auszugehen ist, dass beide Seiten einen entsprechenden Service haben. Aber nicht unter Windows.

[Sir Rufo]

Welches RSync für Windows setzt du denn ein?

Irgendwie sehe ich bei den meisten auch etwas von den Server ("daemon")-Funktionen

[Dalai]

Zitat:

Zitat von Memnarch (Beitrag 1265150)

Unter windows gibt es KEINEN gegenpart. Da ist niemand der mit dem Client quatschen kann. Auf Linux mag RSync ja quasibestandteil sein, womit davon auszugehen ist, dass beide Seiten einen entsprechenden Service haben. Aber nicht unter Windows.

Das spielt doch keine Rolle, ob es einen Daemon gibt oder nicht, und hat nebenbei auch gar nichts mit Windows zu tun. Auch unter Linux ist standardäßig kein Daemon aktiv (man muss für diesen erst eine Konfigurationsdatei erzeugen und dann den Daemon aktivieren). Wenn es nun keinen "Gegenpart", wie du ihn nennst, gibt, dann macht eben ein und derselbe Rsync die ganze Arbeit und vergleicht Quelle mit Ziel. Es gibt drei verschiedene Modi, in denen Rsync arbeiten kann

• Vergleich lokaler Verzeichnisse, die entweder tatsächlich lokal sind oder via SMBFS/CIFS, SSHFS, NFS etc gemountet sein können
• Remote-Shell (SSH) mit Syntax [USER@]HOST:SRC
• Rsync-Daemon mit Syntax rsync:// oder [USER@]HOST::SRC (doppelter Doppelpunkt im Gegensatz zur Remote-Shell)

In der ersten Variante gibt's auch unter Linux keinen Gegenpart, d.h. dort macht (logischerweise) ein und derselbe Rsync die Berechnung der Prüfsummen für Quelle und Ziel.

Bis auf die Remote-Shell funktioniert das vermutlich unter Windows genauso. Das ist übrigens fast unabhängig davon, ob nun ein Rsync-Daemon für Windows existiert, denn man kann ja einfach Quelle und Ziel vertauschen (Push vs. Pull), wenn man zwischen Windows und Linux vergleicht. Zwischen zwei Windows-Systemen sieht die Sache ggf. wieder anders aus. Sehr wahrscheinlich ist die Syntax der Verzeichnisse unter Windows etwas anders, cwrsync z.B. macht sowas: /cygdrive/c/source_directory statt der unter Windows üblichen Syntax C:\source_directory (unabhängig jetzt von Slash oder Backslash, denn auch Windows kennt seit Win2k den Slash als Verzeichnistrenner).

Zitat:

Zitat von Sir Rufo

Welches RSync für Windows setzt du denn ein?

Das ist in der Tat eine nicht unerhebliche Frage.

MfG Dalai

[Memnarch]

Zitat:

In der ersten Variante gibt's auch unter Linux keinen Gegenpart, d.h. dort macht (logischerweise) ein und derselbe Rsync die Berechnung der Prüfsummen für Quelle und Ziel.

Das macht irgendwie keinen SInn. Den dafür müsste RSync die Remote-Daten runterladen, Checksums generieren, änderungen hochladen. Da lässt sich auch gleich die Datei einfach rüberschieben.

Zitat:

Welches RSync für Windows setzt du denn ein?

Ich nutze gerade gar nichts. Mir war nur das Konzept schwammig bezüglich nur eines einseitigen RSyncs. Das nimmt RSync ja jeden vorteil.

[himitsu]

Zitat:

Zitat von Memnarch (Beitrag 1265487)

Das macht irgendwie keinen SInn. Den dafür müsste RSync die Remote-Daten runterladen, Checksums generieren, änderungen hochladen. Da lässt sich auch gleich die Datei einfach rüberschieben.

Mit viel Down- und wenig Upload, ist es so dennoch schneller (solange die andere Seite auch genügend Upload bietet). :stupid:

Im Extremfall (alles muß neu übertragen werden) ist es bei halbem Upload genauso schnell. (außer man weiß daß eine Datei definitiv lokal geändert wurde und braucht nicht mehr auf dem Server nachsehn, bzw. man prüft anfangs auch erstmal nur die Dateigröße und vergleicht den Inhalt dann nicht mehr)

[Memnarch]

Jein ok. Theoretisch. Aber wen du RSync in einem Klingeldrahtnetzwerk hast dann bringt dass SEHR wenig.

[Dalai]

Zitat:

Zitat von Memnarch (Beitrag 1265487)

Zitat:

In der ersten Variante gibt's auch unter Linux keinen Gegenpart, d.h. dort macht (logischerweise) ein und derselbe Rsync die Berechnung der Prüfsummen für Quelle und Ziel.

Das macht irgendwie keinen SInn. Den dafür müsste RSync die Remote-Daten runterladen,[...]

Beim Vergleich lokaler Verzeichnisse gibt es keine Remote-Daten sondern nur ein Quell- und Zielverzeichis! Selbst wenn ein Verzeichnis (oder beide) via Remote-Dateisystem gemountet sind, zieht halt das System die Dateien. Rsync bekommt davon gar nichts mit, weil das für ihn vollkommen transparent ist, ob das ein echtes lokales Verzeichnis oder von einem anderen System gemountet ist. Also nicht Rsync zieht die Dateien sondern die darunterliegende Schicht (SMB, NFS, SSH oder sonstwer). Das muss man schon auseinanderhalten. Ob das nun sinnvoll ist, Rsync in dieser Variante einzusetzen, bleibt dahingestellt.

Ach übrigens: Sofern Größe, Zeitstempel, Eigentümer, sonstige Rechte (ACLs, user_xattr etc) von Quelle und Ziel übereinstimmen, fängt Rsync gar nicht erst an, die Dateien genauer zu untersuchen - es sei denn, man nutzt Schalter -c, der dann jede Datei komplett nach Inhalt vergleicht (Checksums). Insofern bringt auch Rsync über (d)ein Klingeldrahtnetzwerk was.

MfG Dalai