- Das in macOS integrierte Dateisynchronisierungstool basierte lange auf dem Stand von 2006, nun hat Apple rsync 2.6.9 durch openrsync ersetzt
- Das bisherige macOS-rsync erhielt zwar notwendige Korrekturen für Sicherheits- und andere Probleme, enthielt aber keine rsync-3.x-Funktionen nach 2.6.9
- Der zentrale Hintergrund des Wechsels ist der Lizenzunterschied: rsync 2.x wird unter GPLv2, rsync 3.x unter GPLv3 verteilt
- openrsync ist mit rsync kompatibel, unterstützt aber nur einen Teil der Kommandozeilenargumente, weshalb bestehende Skripte unter Sequoia möglicherweise nicht unverändert funktionieren
- Seit macOS 15.4 zeigt
/usr/bin/rsync auf openrsync, daher sollten Mac-Administratoren die Kompatibilität unterstützter Optionen und bestehender Automatisierungen prüfen
Das lange in macOS verbliebene rsync 2.6.9
- rsync ist ein Kommandozeilenwerkzeug zum Übertragen und Synchronisieren von Dateien auf Unix-artigen Betriebssystemen
- Es kann zwischen direkt an denselben Computer angeschlossenen Speichermedien verwendet werden
- Es lässt sich auch zum Synchronisieren von Dateien mit anderen Computern im Netzwerk einsetzen
- macOS enthielt lange Zeit rsync, doch die von Apple bereitgestellte Version war die letzte Version der rsync-2.x-Reihe, rsync 2.6.9
- rsync 2.6.9 wurde im November 2006 veröffentlicht, und Apple aktualisierte rsync in macOS auch nach Erscheinen von rsync 3.x nicht auf spätere Versionen
- Apple spielte für das in macOS enthaltene rsync 2.6.9 zwar Updates für Sicherheitsprobleme und andere Fehler ein
- Bis macOS Sequoia basierte Apples rsync jedoch auf einem fast 20 Jahre alten Stand und enthielt keine neuen Funktionen, die in späteren rsync-Versionen nach 2.6.9 hinzugekommen waren
Versionsstillstand durch GPLv2 und GPLv3
- rsync 2.x und 3.x werden unter unterschiedlichen GPL-Lizenzversionen verteilt
- Apple war der Ansicht, die Bedingungen von GPLv2 für rsync 2.x einhalten zu können, die Bedingungen von GPLv3 für rsync 3.x jedoch nicht
- Deshalb wurde rsync 3.x nicht für macOS bereitgestellt
Der Umstieg auf openrsync in macOS Sequoia
- In macOS Sequoia hat Apple rsync 2.6.9 durch openrsync ersetzt
- openrsync ist eine rsync-Implementierung, die nicht die GPL verwendet
- openrsync wird unter der ISC license verteilt, einer der BSD-artigen Lizenzen
- Die ISC license ist eine permissive Lizenz und legt nur minimale Einschränkungen für Nutzung, Änderung und Verbreitung der betroffenen Software fest
- Apple kam zu dem Schluss, dass sich die Lizenzbedingungen von openrsync im Gegensatz zu den GPLv3-Bedingungen von rsync 3.x einhalten lassen
Wichtige Kompatibilitätsunterschiede für Mac-Administratoren
- Apple kann künftig aktualisierte openrsync-Versionen bereitstellen, ohne sich um GPL-Compliance-Probleme bei rsync sorgen zu müssen
- Die größere praktische Änderung ist jedoch, dass openrsync trotz Kompatibilität mit rsync nur einen Teil der rsync-Kommandozeilenargumente zulässt
- Funktionen von rsync, die auf bisherigen macOS-Versionen funktionierten, können unter macOS Sequoia fehlschlagen
- Der Grund ist, dass die betreffende Funktion im mit Sequoia ausgelieferten openrsync-Kommandozeilenwerkzeug möglicherweise nicht vorhanden ist
- Welche Funktionen openrsync in macOS Sequoia unterstützt, lässt sich auf der openrsync-Handbuchseite nachlesen
So lässt sich das unter macOS 15.4 prüfen
- Stand macOS 15.4 ist das Werkzeug openrsync mit
/usr/bin/rsync verknüpft
- Nutzer können openrsync wie bisher über das rsync-Kommandozeilenwerkzeug ausführen
- Die openrsync-Versionsinformation lässt sich mit folgendem Befehl prüfen
/usr/bin/rsync --version
- Die Ausgabe sieht etwa so aus
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
- In der Ausgabe werden protocol version 29 und rsync version 2.6.9 compatible angezeigt
1 Kommentare
Meinungen auf Hacker News
Die Dokumentation von openrsync ist viel zu dürftig, um Vertrauen zu schaffen, dass es rsync ersetzen kann.
Ein Dateikopierprogramm sollte eine vollständige Kopie erstellen können, ohne ein einziges Bit der Daten und Metadaten des Originals zu verlieren; andernfalls halte ich es für unbrauchbar.
Viele Kopier-/Archivierungswerkzeuge aus der Unix-Welt erstellen mit den Standardoptionen keine vollständigen Kopien, und bei manchen Tools ist das mit keiner Option möglich.
Auch scp habe ich zumindest bis vor einigen Jahren nicht genutzt, weil vollständige Kopien zwischen unterschiedlichen Betriebssystemen oder Dateisystemen schwierig waren; stattdessen habe ich über ssh ausschließlich rsync verwendet.
rsync ist eines der seltenen Tools, das mit den passenden Optionen selbst zwischen unterschiedlichen Betriebssystemen/Dateisystemen, etwa FreeBSD UFS und Linux XFS, Extended Attributes, ACLs und hochpräzise Zeitstempel bewahrt.
Da die openrsync-Dokumentation solche vollständigen Kopien nicht garantiert, gehe ich vorerst davon aus, dass es das nicht kann, und halte es für nutzlos.
Auf der Archivierungsseite kann bsdtar unter Linux beim pax-Format nahezu vollständige Dateikopien speichern; ältere tar-/cpio-Formate können moderne Metadaten nicht aufnehmen.
Normalerweise habe ich rsync als
/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"als Alias eingerichtet.Auch
cpaus coreutils kann mit den richtigen CLI-Optionen und Kompilierungsoptionen vollständige Kopien erstellen, aber einige Distributionen bauen es ohne Unterstützung für Extended Attributes und erstellen dann ohne Warnung oder Fehler nur Teilkopien.Wir stellen alles sehr sorgfältig wieder her, aber manchmal fühlt es sich so an, als wären wir die Einzigen, die sich darum kümmern.
Grundsätzlich würde ich openrsync als rsync mit weniger Lizenzbeschränkungen betrachten, nicht als etwas, das anders funktioniert.
Im README von openrsync steht, es sei mit rsync kompatibel und man solle die rsync-Dokumentation lesen.
Wenn Extended Attributes, ACLs und hochauflösende Zeitstempel auf Protokollebene keine optionalen Funktionen sind, müsste ein Kompatibilitätsanspruch doch bedeuten, dass alles unterstützt wird, was modernes rsync unterstützt.
Oder heißt das, dass es zwar das gesamte Protokoll akzeptiert, Dinge wie ACLs aber einfach verwirft?
Allerdings steht auch auf der offiziellen Website: „We are still working on it... so please wait.“
Diese Nutzer können einfach rsync installieren.
Die in meinem Alias verwendeten Optionen
--xattrs,--aclsund--hard-linksfehlen alle.[0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...
Als noch relativ neuer Linux-Nutzer wirkt die Versionsverwaltung gebündelter System-Utilities auf mich ziemlich chaotisch
Ein typisches Beispiel ist
unzip: Das mitgelieferteunzipauf einem Debian-Server und einem alten Ubuntu-Server konnte keine mit AES-256 verschlüsselten ZIP-Dateien verarbeiten, während es auf Stack Overflow so aussieht, als hätten manche Distributionen es mit entsprechender Unterstützung aktualisiertDas Problem ist, dass ein aktualisiertes
unzipnicht leicht zu finden ist, alle behaupten, „version 6.00“ zu sein, sich tatsächlich aber unterschiedlich verhalten, und dass man selbst dann nicht weiß, ob es sicher ist, das System-Bundle zu ersetzenAm Ende kann man eine gute Funktion, die jemand zu einem weit verbreiteten Utility hinzugefügt hat, trotzdem nicht nutzen; gerade weil es ein zentrales System-Utility ist, fühlt es sich eher schwerer zu aktualisieren an als ein Third-Party-Tool
Windows oder macOS sind bei System-Utilities vielleicht ähnlich oder noch schlechter, aber ich hatte erwartet, dass Linux so etwas besser handhabt
unzipbesser 7z verwendenIch kann mich kaum erinnern, unter Linux für ZIP oder Archive allgemein
unzipbenutzt zu habenNach der Unix-Philosophie ist auch der Ablauf natürlich, einfache Tools, die jeweils eine Sache gut machen, per Pipe zu verbinden: mit tar bündeln, mit gzip komprimieren und mit pgp verschlüsseln
Was die Versionen angeht, ist nicht ganz klar, warum Debian und Ubuntu beide 6.00 angeben, aber üblich ist das nicht
Auf persönlichen Geräten folgen Rolling-Release-Distributionen wie Arch oder Manjaro den Upstream-Versionen kontinuierlicher, bringen aber mehr Wartungsaufwand und höhere Erwartungen an die eigene Verwaltung mit sich
Was bei der Versionsverwaltung in Linux/Open Source noch störender ist: Bibliotheken schieben die Erklärung von v1.00 übermäßig lange hinaus
Obwohl sie im Ökosystem weit verbreitet, stabil und funktional nahezu vollständig sind, bleiben sie jahrelang bei v0.2 oder v0.68 und verwirren damit Einsteiger
Debian hat lange Release-Zyklen, ist aber sehr stabil, und in stable passt alles gut zusammen
Ubuntu fühlt sich im Grunde wie Debian plus „Was wäre, wenn wir häufiger releasen?“ an
Wer aktuelle Tools will, muss weniger stabile Optionen wie Nix oder Arch in Kauf nehmen; beide sind nicht gerade besonders einsteigerfreundlich
Wenn man sowohl Stabilität als auch aktuelle Tools will, ist Gentoo ein Weg, aber noch aufwendiger als Arch
Wenn man Stabilität und Einfachheit will, kann man zulasten von Speicherplatz Ansätze wie Docker/podman, flatpak, appcontainers oder snap nutzen
Windows und Mac haben dasselbe Problem, und Windows hat es gelöst, indem es alte Bibliotheken mitliefert und je nach laufender App dynamisch verlinkt
unzipist ein SonderfallDie Upstream-Entwicklung ist praktisch stehen geblieben, und das letzte Release war 6.0 aus dem Jahr 2009
Nachdem später verschiedene Probleme entdeckt wurden und auch Funktionen fehlten, haben die einzelnen Distributionen jede Menge Patches auf dieses Release gepackt; dadurch entstanden sehr unterschiedliche ausführbare Dateien mit derselben Versionsnummer
[0]: https://infozip.sourceforge.net/UnZip.html
[1]: Im Build-Rezept von Arch sieht man, wie viele Patches angewendet werden: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
Ein gewisses Maß an Interoperabilität ist gut, aber die Vielfalt der Auswahlmöglichkeiten ist ebenfalls ein Vorteil
In den Repositories der meisten Distributionen gibt es bsdtar, das man stattdessen ausprobieren kann; je nach Distribution kann der Paketname libarchive lauten
Schon
bsdtar xf path/to/filekann fast alle Formate entpacken und unterstützt auch AES bei ZIPIn macOS ist es standardmäßig enthalten, und in Windows ist es vermutlich ebenfalls enthalten
Für alles, was ich tue, lege ich ein git-Repository und eine
flake.nixan und lasse direnv beim Betreten des Verzeichnisses die in der Flake deklarierte Umgebung aktivierenWenn ich ein Skript schreibe, das
grepverwendet, lege ich das Skript ins Repository und füge auchpkgs.gnugrepzuflake.nixhinzuSo wird nicht die Systemversion verwendet, sondern die deklarierte Version, und wenn man von macOS nach Linux oder WSL wechselt, wird dieselbe grep-Version aufgerufen
Nix gilt vielen als wenig anfängerfreundlich, daher würde ich es nur vorsichtig direkt empfehlen; der Kern ist aber, Abhängigkeiten auf irgendeine Weise zu deklarieren und nur die deklarierten Abhängigkeiten zu verwenden
Docker geht ebenfalls, und Sprachökosysteme wie Python/Node.js/Go/Rust bieten auch Wege, Abhängigkeiten zu bündeln und aufzurufen
Dadurch bleiben Updates von Abhängigkeiten als Commits erhalten, sodass man bei einem Bruch zu einem früheren Commit zurückkehren kann
Ein solches Repository muss nicht unbedingt ein Softwareprojekt sein; es kann auch einfach eine „Sammlung von Tools sein, die man für XYZ braucht“
Dass openrsync einige Funktionen von rsync nicht unterstützt, ist etwas lästig
Trotzdem ist es gut, dass es inzwischen mehrere unabhängige Implementierungen von rsync gibt
Denn das bedeutet, dass rsync nicht nur als einfache Software, sondern tatsächlich eher wie ein Protokoll behandelt wird
Wenn es protokollähnlicher wird, könnte es auch Ansatzpunkte für eine Binary-Diff-API auf Basis des rsync-Algorithmus geben
Interessanterweise nutzte Dropbox intern rsync-Binary-Diffs, um kleine Änderungen an großen Dateien schnell hochzuladen
Ich nehme an, dass das immer noch so ist, aber in den öffentlichen API-Endpunkten gibt es diese Funktion nicht; selbst bei nur kleinen Änderungen an großen Dateien muss man daher die gesamte Datei erneut hochladen
Das ist in Unternehmensumgebungen ziemlich nützlich, wenn SSH+rsync blockiert ist, der Aufbau von gRPC-Services aber erlaubt ist
rsync hat viele Funktionen, daher wird das zwangsläufig eine ganze Weile dauern
In den Mainline-rsync-Patches wurde zur Unterstützung von macOS-Metadaten Unterstützung für erweiterte Attribute hinzugefügt
Bombichs „Carbon Copy Cloner“ ist eine GUI-App darum herum
https://support.bombich.com/hc/en-us/articles/20686446501143...
Mike Bombich kannte ich aus Beiträgen im Forum für macOS-Server-Systemadministratoren, und es gibt auch dazugehörige Materialien
https://web.archive.org/web/20140707182312/http://static.afp...
Nathaniel Gray entwickelte Backup Bouncer, das die Backup-Treue unter anderem für mehrere Streams, erweiterte Attribute und ACLs überprüft
https://github.com/n8gray/Backup-Bouncer
Es gibt auch RsyncX, eine SwiftUI-App als Wrapper um rsync
https://github.com/rsyncOSX/RsyncOSX
In der Zeit, als „Classic“-macOS-Software auf dem neuen UNIX-System lief, hielt man solche Dinge für wirklich wichtig
https://web.archive.org/web/20161022012615/http://blog.plast...
IFileOperation (Windows) und FileManager (macOS) führen die performanteste Kopie aus, die das zugrunde liegende Dateisystem unterstützt
Bei SMB und ReFS ist die CRC-Prüfung praktisch nur eine Checkbox, und bei modernen SMB-Shares auf modernem Windows Server ist die Content-Matching-Phase von rsync doppelte Arbeit
Zwischen Windows-Systemen kann IFileOperation 1,5- bis 8-mal mehr Durchsatz als rsync erzielen und zugleich weniger CPU verbrauchen; außerdem kann es 1,2- bis 3-mal schneller sein als eine normale Dateikopie in Go
Wenn man Betriebssysteme ignoriert, die komplexe Dateisystem-Metadaten tatsächlich nutzen, und nur auf Linux schaut, reichen openrsync oder noch einfachere Programme aus
Ich frage mich, ob es eine gute Erklärung dafür gibt, warum Apple solche Angst vor GPLv3 hat
Wenn man die ausführbare Datei statisch kompiliert, sollte das doch eigentlich kein Problem sein
TiVo machte das damals so, weshalb es Tivoisierung genannt wurde
Bei iOS ist klar, warum GPLv3 nicht verwendet wird: Man würde gegen die Bedingungen verstoßen
In macOS könnte man GPLv3-Code ausliefern, aber Apple teilt sehr viel Code zwischen iOS/macOS/watchOS/tvOS/visionOS; daher ergibt es wenig Sinn, sich nur in einem Betriebssystem auf GPLv3 zu stützen und in den übrigen nicht
Es ist einfacher, es gar nicht zu verwenden
Außerdem muss man sich dann keine Sorgen machen, GPLv3-Code später herauszureißen, falls macOS künftig stärker gegen die Ausführung von Nutzer-Code abgeschottet wird
Dinge, die ich für völlig sicher hielt, waren aus Sicht von Juristen keineswegs so eindeutig
Apples Gründe kenne ich nicht, aber Unternehmensjuristen anderer Firmen gaben als Grundsatz vor, nach Möglichkeit Nicht-GPL-Lizenzen zu wählen
Wenn man sich die Rechtsprechungsgeschichte zu GPLv2 ansieht, scheint der Ertrag im Verhältnis zum Aufwand gering
Aus Apples Sicht lässt sich die gesamte Problemkategorie vermeiden, indem man die Teile, die als „Problem“ erscheinen, einfach ersetzt
Die technischen Detailfragen mögen interessant sein, aber ich halte sie nicht für den Kern der Sache
Erklärungen anderer Leute zu Apples Absichten sollte man besser nicht glauben
Als ich selbst an einer Implementierung von https://github.com/gokrazy/rsync in Go gearbeitet habe, habe ich mir openrsync angesehen; der Code war gut.
Schade ist allerdings, dass openrsync nicht 100 % kompatibel mit rsync ist.
Dass Apple mit der Umstellung auf openrsync begonnen hatte, merkte ich, als meine Tests unter macOS 15 kaputtgingen.
Es heißt, openrsync sei als Teil des Projekts rpki-client(1), eines RPKI-Validators für OpenBSD, geschrieben worden und von NetNod, IIS.SE, SUNET und 6connect finanziert worden; ich frage mich, warum diese Organisationen diese Entwicklung finanziert haben.
https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...
https://news.ycombinator.com/item?id=43605846
Unternehmen finanzieren Dinge, die nützlich oder notwendig sind.
Einige der Unternehmen in der Liste könnten BSD einsetzen und wollten oder brauchten möglicherweise eine rsync-Implementierung, die nicht GPLv3 ist.
Oder sie hatten schlicht Interesse daran, Open-Source-Projekte und -Entwicklung zu unterstützen.
Eine Zeit lang, bis Sequoia 15.3, konnte man über
/var/select/rsyncoder die UmgebungsvariableCHOSEN_RSYNCsowohl rsync_samba als auch rsync_openrsync verwenden.Besonders nervig an openrsync war, dass es behauptete, das magische Pfadelement
/./für--relativezu unterstützen.Wegen dieses Problems habe ich vor etwa einem Monat einen Bug-Report an Apple geschickt.
Seit Sequoia 15.4 ist rsync_samba verschwunden, und ich habe rsync per Homebrew installiert.
Kürzlich bin ich auf dieses Problem gestoßen: Wenn man auf der Kommandozeile mit
xcodebuildeine iOS-.ipaerstellt, scheint es intern rsync aufzurufen, um Dateien zwischen lokalen Verzeichnissen zu kopieren.Da im
$PATHjedoch Homebrews rsync weiter vorn stand, wurde dieses ausgeführt, undxcodebuildübergab das openrsync-spezifische Argument--extended-attributes.Homebrews rsync verstand dieses Argument nicht, schlug fehl und beendete sich.
Ich finde es weiterhin erfreulich, dass Apple nicht nach und nach die POSIX-Seite entfernt, um osx wie iOS zu machen, sondern sie weiter verbessert und annimmt.