Diskussion:Rsync

message: !!! Bitte den ersten Absatz überarbeiten !!! Da ist ja quasi alles falsch !!!
: Ist diese These noch aktuell? Warum kann man nicht signieren, daß Wissenssuchende hinterher wenigstens das Datum sehen? 217.237.150.52 17:06, 3. Feb. 2008 (CET)
replies: text: „When Rsync is communicating with a daemon it is communicating directly with a network socket. This is the only sort of Rsync communication that could be called network aware. ... The data is transferred as an unbroken stream of bytes.“ Sowas als Netzwerkprotokoll zu bezeichnen, ist ziemlich überzogen. rsync ist ein Programm, das auch einen Port öffnen kann, aber das macht seine Dokumentation nicht zur Spezifikation eines Netzwerkprotokolls. --84.157.202.134 17:10, 17. Nov. 2012 (CET)
thread_title:  Bitte den ersten Absatz überarbeiten (2007) 

message: Hallo,
was hat es damit auf sich, habe dazu im Web leider nichts gefunden!
grüße Bartelbie 21:18, 17. Mai 2009 (CEST)
thread_title:  Reverse Deltas? 

message: Auf einer anderen Seite habe Ich gelesen das rsync standardmässig Unterschiede anhand der mtime und der Grösse ausmacht und sollte man es anders haben wollen muss man das über einen Parameter mit angeben, in dem Artikel hier heisst es das Prüfsummen der Dateien genommen werden. Was ist denn jetzt richtig? Oder vertuhe Ich mich irgendwie?!grüßeBartelbie 15:52, 18. Mai 2009 (CEST)
replies: text: Ja, die Seite hat Recht: Der Empfänger schickt dem Sender eine Liste von Dateien, die er bereits hat. Der Sender entscheidet daraufhin anhand von Größe und Änderungszeitpunkt (mtime) ob die Datei geändert wurde und fordert ggf. die Checksummen vom Client an. Wenn die Option --checksum gegeben ist, berechnet der Empfänger eine Checksumme über die gesamte Datei und versendet diese Checksumme in der Dateiliste. Siehe auch: rsync(1), insbesondere die Dokumentation der Option --checksum. Grüße, -- octo 17:30, 18. Mai 2009 (CEST)
thread_title:  Funktionsweise bzw. Prüfsummen 

message: Ich bin frustriert, weil nirgendwo konkrete Beispiele (nicht Muster (patterns), davon gibts genug, aber sie erklären sich nicht selbst) für Kommando-basierende Befehle (oder Scripts mit solchen) gegeben werden.
Ich habe einen Zugang zu einem Unix-Rechner, ich habe eine Kommandoshell und ich habe dort ein funktionierendes (?) rsync und kann nichts damit anfangen, weil alle Muster oder Hilfen und auch die Quellen im Web zum Thema rsync keine wirkliche Hilfe geben.--Wikipit 14:40, 1. Dez. 2009 (CET)
replies: text: RTFM! Wikipedia ist nicht der Erklärbär. http://rsync.samba.org/ftp/rsync/rsync.html 85.178.213.185 19:16, 29. Jan. 2010 (CET)

text: Ein "kurzes" Beispiel ist nicht möglich, da rsync zu grundlegend und flexibel ist. Die Möglichkeiten sind zu vielfältig. --Christian Buhtz (Diskussion) 14:15, 21. Dez. 2023 (CET)
thread_title:  Kommandobeispiele? 

message: Wenn ich jetzt nicht gerade auf meiner Leitung sitze, stimmt im Absatz
"Mit den Prüfsummen ..."
etwas nicht. Da ja laut erstem Absatz vom Client auf den Server kopiert wird, sind doch im genannten Absatz Client und Server vertauscht, oder?
-- MiLuZi 20:43, 22. Nov. 2011 (CET)
replies: text: Der Server generiert die Anweisungen (nur er hat Zugriff auf die neue Version der Datei. Der Client führt diese Anweisungen durch, wodurch er eine Kopie der neuen Version erhält. Ist das so verständlich? Würde mich freuen, wenn du den Artikel verständlicher machen könntest. Zögere nicht weitere Fragen zu stellen. --Blauebirke ☕✍  10:32, 25. Nov. 2011 (CET)
replies: text: Vielleicht sollte man das mit "Server" und "Client" heutzutage über Bord werfen, da es mehr für Verwirrung sorgt. Heutzutage kann doch jeder Computer "Server" sein und bei manchen technischen Dingen ist es nicht so einfach zu verstehen wer Server und wer Client ist. (z.B. bei X11 und ssh, wo dann der lokale PC zum Server wird wenn man sich die grafische Ausgabe des Servers lokal anzeigen lässt. oder so ähnlich..) Dann lieber C1 und C2 oder Computer1 und Computer2 oder R1/R2, Rechner1/Rechner2. (nicht signierter Beitrag von 79.242.159.70 (Diskussion) 21:55, 19. Nov. 2013 (CET)
thread_title:  Funktionsweise 

message: Unter Abschnitt Frontends für OSX habe ich backuplist+ hinzugefügt und an erste Stelle gesetzt, da es im Gegensatz zu arRsync aktuell noch weiterentwickelt wird. -- 85.178.7.4 11:51, 13. Jan. 2012 (CET)
thread_title:  Backuplist+ hinzugefügt 

message: Disclaimer: Ich bin selbst Upstream-Betreuer von "Back In Time", dass rsync nutzt und hier im Artikel auch genannt und indirekt verlinkt wird.
Der Artikel gibt fremder Software zu viel Raum. Eine kurze Auflistung von Anwendungen, die ebenfalls rsync nutzen, wäre IMHO OK. Aber eine (marketingmäßige) Beschreibung der Funktionen usw der einzelnen Anwendungen finde ich nicht zielführend und auch unfair den anderen ähnlichen Anwendungen über.
Ich würde das übernehmen, sofern es hier ein OK der Moderatoren gäbe und meine Arbeit nicht umsonst wäre. --Christian Buhtz (Diskussion) 14:04, 21. Dez. 2023 (CET)
replies: text: Von mir aus gerne. Ich bitte jedoch um kleinere, konkrete Bearbeitungen mit einer gut dokumentierten Zusammenfassungszeile, damit man die Änderungen gut nachvollziehen kann. ‣Andreas•⚖ 15:21, 21. Dez. 2023 (CET)
thread_title:  Dritt-Software entfernen oder zusammenfassen 

message: Eine optimale Lösung habe ich noch nicht, aber ich würde es tendenziell dünner gestallten (bullet points).
Unter anderem fällt mir auf das "Unison" unter Grafischer Oberfläche geführt wird, was technisch schlicht falsch ist. Unison implementiert(!) Teile(!) des rsync Algorithmus. Es ist also kein Front-End. Das zu korrigieren, würde ich aber mit einer Umstrukturierung verbinden.
Vielleicht eine Überschrift "Relevante Anwendungen" oder nur "Anwendungen"?
Darunter separate Abschnitte bzw. Aufzählungen: "Anwendungen die rsync Nutzen" (unabhängig ob GUI oder CLI) und "Weitere Anwendungen" (hier dann Unison als Teil-Implementierung des Protokolls; und auch Derivate für Windows und andere Alternativimplementierungen).
Vorschläge? --Christian Buhtz (Diskussion) 14:10, 21. Dez. 2023 (CET)
replies: text: Die Relevanz müsste jedoch belegt sein, sonst ist es WP:TF. Darum bin ich eher dafür, das nicht so zu nennen. Besser wäre, wenn sich der Artikel darauf beschränkt, wirklich rsync zu beschreiben, nicht auf rsync aufbauende "Produkte" (Frontends oder Forks bzw. Programme, die Teile des Codes verwenden). Diese würde ich grundsätzlich auch eher nur als Beispiel nennen, e.g. "Frontends für rsync sind beispielsweise QtdSync oder Grsync." Und auf Unison würde ich kurz eingehen, weil es den rsync-Algorithmus verwendet, aber mehr auch nicht: Unison baut nicht auf rsync auf.ref ‣Andreas•⚖ 15:30, 21. Dez. 2023 (CET)
thread_title:  Umstrukturierung der Überschriften bzgl. Anwendungen und Grafischer Oberflächen