Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

macOS 15.4: Apple ersetzt ohne Warnung “rsync” – und sorgt für Probleme

Als Unix-basiertes Betriebssystem setzt macOS auf einen Unterbau auf, der viele weitverbreitete Kommandozeilenwerkzeuge enthält. Diese sind seit Jahren stabiler Bestandteil des Betriebssystems; erfahrene Mac-Administratoren nutzen sie beispielsweise, um Routineaufgaben in Skripten zu automatisieren. Eines davon ist das universelle Synchronisierungswerkzeug „rsync“. Es erlaubt den Abgleich von Dateien und Ordnern an zwei unterschiedlichen Orten – auch über das Netzwerk, beispielsweise eine SSH-Verbindung. Mit macOS 15.4 änderte Apple nun überraschend vom „offiziellen“ rsync auf das alternative openrsync – und leitet Kommandozeilenaufrufe auf die neue Version um. Dies wurde nicht öffentlich gemacht – stattdessen dokumentierte Mac-Administrator Rich Trouton diese potenziell einschneidende Veränderung auf seinem Blog.


Durch die Umleitung fällt die Änderung nicht sofort auf; einige Nutzer bemerkten allerdings, dass ihre Backup-Skripte plötzlich scheiterten. Obwohl Version 29 von openrsync als kompatibel zu rsync version 2.6.9 beschrieben wird, kann sie doch Probleme verursachen. Insbesondere die Option „--logfile=[Dateipfad.log]“ führt anscheinend bei dieser Version dazu, dass eine Synchronisierung abgebrochen wird. Auf der GitHub-Seite des Projekts haben Anwender bereits einen Hinweis auf das Problem hinterlassen. Der Entwickler plant, sich auf Ursachenforschung zu begeben, gibt aber zu bedenken, dass er nicht für Apple arbeite.

Recherche per Terminal
Wer mehr über die verwendete Implementierung erfahren will, kommt um die Kommandozeile nicht herum. Der Befehl

rsync --help

bietet nur bedingt Unterstützung, da auf diese Weise lediglich die gebräuchlichsten Optionen aufgelistet und kurz erläutert werden. Das Resultat sieht zwar anders aus als bei der bisher verwendeten Version 2.6.9 des Original-rsync, doch dies wird nur den versiertesten Administratoren auffallen. Fragt man hingegen die Versionsnummer direkt ab, erscheint der entscheidende Hinweis:

/usr/bin/rsync --version
openrsync: protocol version 29 – rsync version 2.6.9 compatible

Um sich mit den Eigenheiten von openrsync vertraut zu machen, geben Sie „rsync“ in die Kommandozeile ein, ohne den Befehl mit der Eingabetaste zu bestätigen. Über einen Sekundärklick auf das eingegebene Wort öffnen Sie das Kontextmenü, um darin „man-Seite öffnen“ auszuwählen. Sogleich erscheint ein zweites, gelb hinterlegtes Terminal-Fenster, in dem Sie das integrierte Benutzerhandbuch studieren können. Wer auf das "offizielle" rsync wechseln will, kann das am einfachsten mit einem Paketmanager wie Homebrew bewerkstelligen.

Über das Kontextmenü laden Sie die integrierte Nutzungsdokumentation eines Kommandozeilenprogramms in einem zweiten Fenster.

Wahrscheinlicher Grund: Open-Source-Lizenz
Als Ursache für den Wechsel vermutet Trouton den Wechsel der GPL-Lizenz. Die bis zu macOS 15.3 von macOS verwendete rsync-Version trägt die Versionsnummer 2.6.9; diese wurde seit 2006 nicht mehr aktualisiert. Mit Version 3 wechselte rsync auf die neuere Version 3.0 der „General Public License“ (GPL). Bei anderen Kommandozeilenwerkzeugen wurde eine solche Lizenzänderung in der Vergangenheit ebenfalls als Grund angenommen, warum Apple ein Kommandozeilenwerkzeug ersetzte. So setzt Apple seit macOS 10.15 (Catalina) zsh als Standard-Terminal-Shell ein, anstatt bash zu aktualisieren.

Kommentare

wicki
wicki29.04.25 17:34
Off-topic: Das mit dem Recht-Klick "man Seite öffnen" kannte ich auch noch nicht.

Ich habe allerdings mittels ps2pdf ein "superman"-Kommando gebastelt.

#!/bin/sh
man -t $1 > /tmp/$1.ps
ps2pdf /tmp/$1.ps /tmp/$1.pdf
open /tmp/$1.pdf

macht aus der man-Page ein PDF. Finde ich ganz brauchbar.
Better necessarily means different.
+8
Nebula
Nebula29.04.25 18:03
Welchen Vorteil hat das PDF?
»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs
+2
dundo
dundo29.04.25 18:57
Kann Staub ansetzen …
Am Ende bereust du, es nicht getan zu haben. Carpe diem.
+5
PythagorasTraining
PythagorasTraining29.04.25 20:04
Hat das Auswirkungen auf CCC oder SuperDuper?
Die benutzen doch auch rsync.
a² + b² = c² ist nicht der Satz des Pythagoras!
0
stargator29.04.25 20:10
Die haben schon lange ihr eigenes rsync 3.x, wer keines selber übersetzen will kann ja das nehmen.
+4
Stefanie Ramroth29.04.25 20:30
Wer auf das "offizielle" rsync wechseln will, kann das am einfachsten mit einem Paketmanager wie Homebrew bewerkstelligen.
Das Problem ist bei solchen Systembefehlen aber nun, dass die auf dem Snapshot liegen und von SIP geschützt sind.

Man erstellt also entweder Code, in dem fest ein Homebrew-rsync referenziert wird oder man öffnet die Systemversiegelung - und das nach jedem Update erneut. Beides nicht wirklich sauber.

Die beste Alternative: man implementiert in den Skripten eine OS/Versions-Weiche. Wäre die sauberste Lösung. Aber doof, weil es schon wieder mal in einem Minor-Update eine Anpassung erfordert und nicht erst im Major. Irgendwann hat man etliche Zeilen für die Abhängigkeitsprüfungen.

Und auch wenn ich weiß, dass es für den Satz viele Daumen runter gibt: sorry, aber genau das sind so Dinge, die mich an Apple irgendwie nerven.
+7
sudoRinger
sudoRinger29.04.25 20:44
Stefanie Ramroth
Die beste Alternative: man implementiert in den Skripten eine OS/Versions-Weiche. Wäre die sauberste Lösung.
Wenn rsync 3.x per Homebrew installiert ist, liegt es unter /opt/homebrew/bin/rsync (Apple Silicon).
Die sauberste Lösung aus meiner Sicht ist, dass man das entsprechende Homebrew-Verzeichnis im PATH vor /usr/bin platziert. Damit wird automatisch die Homebrew-Version von rsync verwendet, ohne dass man Pfade im Skript fest codieren muss.
Durch die Nutzung von rsync 3.x sind Skripte mit rsync dann auch mit Linux kompatibel.
+8
Nebula
Nebula29.04.25 21:45
Das ist nicht nur die sauberste Lösung, sondern die offizielle, die beim Installieren von Homebrew auch automatisch eingerichtet wird. Stefanies vermutete Problematik ist also keine.
»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs
+4
Mutabaruga29.04.25 22:00
Ist es nicht verwunderlich, dass Apple im Jahrestakt eigene Software raushaut, aber rsync so lange nicht aktualisiert hat? Ich habe nicht die Ahnung, ob sich die Funktionalität groß geändert hat, aber ich vermute bei einem Zeitraum von 21 Jahren schon.
-6
Weia
Weia29.04.25 22:05
sudoRinger
Wenn rsync 3.x per Homebrew installiert ist, liegt es unter /opt/homebrew/bin/rsync (Apple Silicon).
Die sauberste Lösung aus meiner Sicht ist, dass man das entsprechende Homebrew-Verzeichnis im PATH vor /usr/bin platziert.
Und wenn man nicht Homebrew verwendet, sondern rsync einfach selber kompiliert und installiert, speichert man es stattdessen in /usr/local/bin. Das sollte in PATH bereits vor /usr/bin stehen.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
+4
Weia
Weia29.04.25 22:17
Mutabaruga
Ist es nicht verwunderlich, dass Apple im Jahrestakt eigene Software raushaut, aber rsync so lange nicht aktualisiert hat?
Nö, ist es nicht. Der Artikel erklärt doch den Hintergrund: sobald bei irgendwelchen Unix-Tools die Lizenz von GPL2 auf GPL3 umgestellt wurde, fror Apple stets den letzten GPL2-Stand ein.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
+5
Weia
Weia29.04.25 22:20
Nebula
Stefanies vermutete Problematik ist also keine.
Das stimmt nun auch wieder nicht ganz, denn nicht alle Skripte berücksichtigen die PATH-Variable und wenn sie das nicht tun, stehst Du wieder vor dem Problem.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
0
MetallSnake
MetallSnake30.04.25 06:58
Skripte müssen nichts machen, die path variable wird automatisch vom System/shell berücksichtigt.
Damit ein Skript diese nicht berücksichtigt müssen die Pfade zu den Programmen fest kodiert werden, dann passiert das also mit voller Absicht, und wird seinen Grund haben, ansonsten sollte man von dem Skript wohl lieber Abstand halten wenn sonstwas grundlegendes schon falsch gemacht wird
The frontier of technology has been conquered, occupied and paved over with a parking lot.
+5
MetallSnake
MetallSnake30.04.25 07:03
Mutabaruga
Ist es nicht verwunderlich, dass Apple im Jahrestakt eigene Software raushaut, aber rsync so lange nicht aktualisiert hat?

Nein, wird im Artikel auch erwähnt. Bei GPL 3 wurden ein paar Schlupflöcher geschlossen. Die so lizenzierten Programme müssen auf dem jeweiligen System kompilierbar und dort einsetzbar sein. Das ist unter iOS nicht gegeben, und weil Apple vieles zwischen macOS und iOS teilt bleibt es auch dort bei der GPL 2 Version.
The frontier of technology has been conquered, occupied and paved over with a parking lot.
+4
milk
milk30.04.25 09:38
Weia
Und wenn man nicht Homebrew verwendet, sondern rsync einfach selber kompiliert und installiert, speichert man es stattdessen in /usr/local/bin.
Wobei es natürlich keinen sinnvollen Grund gibt, Binaries selber zu kompilieren und dadurch auf ein automatisiertes Dependency Management zu verzichten.
+3
LoCal
LoCal30.04.25 09:39
Weia
sudoRinger
Wenn rsync 3.x per Homebrew installiert ist, liegt es unter /opt/homebrew/bin/rsync (Apple Silicon).
Die sauberste Lösung aus meiner Sicht ist, dass man das entsprechende Homebrew-Verzeichnis im PATH vor /usr/bin platziert.
Und wenn man nicht Homebrew verwendet, sondern rsync einfach selber kompiliert und installiert, speichert man es stattdessen in /usr/local/bin. Das sollte in PATH bereits vor /usr/bin stehen.

Ich bin wohl nicht der einzige, der Dingen wie Homebrew nicht traut
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
-2
Marcel Bresink30.04.25 09:53
Mutabaruga
Ist es nicht verwunderlich, dass Apple im Jahrestakt eigene Software raushaut, aber rsync so lange nicht aktualisiert hat?

Das stimmt so nicht. Apple hat rsync ständig aktualisiert. In macOS 13 trägt rsync Apples Versionsnummer 57, in macOS 14 ist es Apple-Version 62.

Was Du in Wirklichkeit meinst, ist, dass Apple seit dem 30.10.2007 keinen Code mehr aus dem früheren rsync-Projekt übernommen hat, denn das durften sie aus rechtlichen Gründen nicht mehr. Seitdem war Apple gezwungen, das als eigenen Zweig selber weiterzuentwickeln. Mit macOS 15 wurde dann schließlich auf openrsync gewechselt und ab 15.4 wird das alte rsync nicht mehr mitgeliefert.

Wer wirklich hundertprozentige Kompatibilität braucht, kann eigentlich auch kein rsync 3 verwenden. Man müsste Apples letzte rsync-Version 62 aus dem Quellcode von Darwin 23.6 (macOS 14.6) herunterladen und für Sequoia kompilieren:
+2
Weia
Weia30.04.25 11:44
MetallSnake
Skripte müssen nichts machen, die path variable wird automatisch vom System/shell berücksichtigt.
Darauf kannst Du dich nicht verlassen. Das hängt immer davon ab, welcher Prozess ein Skript startet.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
-1
Weia
Weia30.04.25 11:50
milk
Wobei es natürlich keinen sinnvollen Grund gibt, Binaries selber zu kompilieren und dadurch auf ein automatisiertes Dependency Management zu verzichten.
Ich kenne einige sinnvolle Gründe. Homebrew etwa käme mir sicher nicht ins Haus, da es keine Standardpfade nutzt und Permissions verbiegt. Außerdem entscheide ich gerne selbst, was ich wie genau kompiliere.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
0
sudoRinger
sudoRinger30.04.25 12:15
Weia
milk
Wobei es natürlich keinen sinnvollen Grund gibt, Binaries selber zu kompilieren und dadurch auf ein automatisiertes Dependency Management zu verzichten.
Ich kenne einige sinnvolle Gründe. Homebrew etwa käme mir sicher nicht ins Haus, da es keine Standardpfade nutzt und Permissions verbiegt. Außerdem entscheide ich gerne selbst, was ich wie genau kompiliere.
Auf Apple Silicon Macs installiert Homebrew in /opt/homebrew statt in /usr/local/Cellar, was das Problem der nicht-standardkonformen Pfade entschärft. Als Alternative bietet sich Nix an, das echte Isolation der Pakete sowie Multi-User-Support bietet. Dann muss man dennoch keine Binaries selber kompilieren oder sich um Abhängigkeiten kümmern.
Ich überlege, Nix auszuprobieren, obwohl Homebrew für meine aktuellen Bedürfnisse eigentlich ausreicht. Hat jemand damit Erfahrung?
+1
LoCal
LoCal30.04.25 14:14
milk
Weia
Und wenn man nicht Homebrew verwendet, sondern rsync einfach selber kompiliert und installiert, speichert man es stattdessen in /usr/local/bin.
Wobei es natürlich keinen sinnvollen Grund gibt, Binaries selber zu kompilieren und dadurch auf ein automatisiertes Dependency Management zu verzichten.

Ich erinnere mich nur zu gut an diesen Fall von vor ein paar Jahren. Natürlich sind homebrew & Co nicht so dynamisch wie dieses ganze Webgefrickel, ABER trotzdem ist es eine fantastische Möglichkeit unschöne Sachen zu verteilen und die User checken es nicht, weil die ja schön ihr "Y" setzen.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
-2
Fischmuetze30.04.25 16:52
LoCal
milk
Weia
Und wenn man nicht Homebrew verwendet, sondern rsync einfach selber kompiliert und installiert, speichert man es stattdessen in /usr/local/bin.
Wobei es natürlich keinen sinnvollen Grund gibt, Binaries selber zu kompilieren und dadurch auf ein automatisiertes Dependency Management zu verzichten.

Ich erinnere mich nur zu gut an diesen Fall von vor ein paar Jahren. Natürlich sind homebrew & Co nicht so dynamisch wie dieses ganze Webgefrickel, ABER trotzdem ist es eine fantastische Möglichkeit unschöne Sachen zu verteilen und die User checken es nicht, weil die ja schön ihr "Y" setzen.

Wenn es manipulierten code im Repo gibt, nützt dir das selbst compilieren auch nix … man denke nur an XZ-Tools …
+2
LoCal
LoCal30.04.25 21:19
Fischmuetze
Wenn es manipulierten code im Repo gibt, nützt dir das selbst compilieren auch nix … man denke nur an XZ-Tools …

Es geht doch dabei gar nicht um das eigentliche Projekt, das man sich via PaketManager laden will. Es geht dabei um die RelationChain, die sich das mitzieht und da verlierst Du eben die Kontrolle.
Und wie gesagt, homebrew ist da relativ statisch. Wenn man sich da was kompiliert, dann macht man das einmal und genauso einmal zieht man die ReleationChain.

Bei der oben verlinken JavaScript-Sache war das gravierender.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.