Why iCloud Fails: The Category Mistake of Cloud Synchronization

Diese Arbeit argumentiert, dass iCloud Drive aufgrund einer fundamentalen Kategorienverwechslung, bei der ein verteilter kausaler Graph fälschlicherweise auf eine lineare Zeitachse projiziert wird, mit POSIX-konformen Workflows und Tools wie Time Machine oder Git unvereinbar ist, und schlägt als Lösung die physikalisch fundierten, reversiblen Transaktionssemantiken von Open Atomic Ethernet vor.

Das Wesentliche

Warum iCloud manchmal verrückt spielt: Ein Missverständnis der Natur

Stell dir vor, du hast einen magischen Koffer (iCloud). Du legst ein Foto hinein, und plötzlich ist es auch auf deinem Handy, deinem Laptop und dem Tablet deines Partners. Das klingt toll, oder? Apple verspricht dir: „Es ist wie ein normaler Ordner auf deinem Computer, nur überall gleichzeitig."

Das Problem ist: Es ist kein normaler Ordner. Es ist ein Koffer, der versucht, Magie vorzutäuschen, aber die Gesetze der Physik und der Mathematik nicht beachtet. Der Autor dieses Dokuments, Paul Borrill, sagt: iCloud macht einen fundamentalen Fehler, den er eine „Kategorien-Fehlleistung" nennt.

Hier ist die einfache Version, was schiefgeht und warum:

1. Der große Irrtum: Der Koffer ist kein Regal

Ein normaler Computer-Ordner ist wie ein festes Regal in deinem Haus. Wenn du ein Buch dort hineinstellst, ist es da. Wenn du es nimmst, ist es weg. Es ist stabil.

iCloud ist wie ein Kurierdienst, der versucht, das Regal zu simulieren.

• Das Problem: Der Kurierdienst (iCloud) sagt dir: „Das Buch ist im Regal!" (Du siehst den Namen der Datei). Aber wenn du es greifen willst, ist es vielleicht noch nicht angekommen, oder der Kurier hat es schon wieder weggebracht, um Platz zu sparen.
• Die Folge: Programme wie Git (für Programmierer) oder Time Machine (für Backups) gehen davon aus, dass das Buch wirklich da ist. Wenn sie es nicht finden, stürzen sie ab oder löschen Dinge versehentlich. Es ist, als würdest du versuchen, ein Haus zu bauen, indem du auf Luft stehst, die wie ein Boden aussieht.

2. Der Zeit-Strich und die Zeitmaschine

Stell dir vor, du und dein Freund schreiben beide an demselben Roman.

• Wie es funktionieren sollte: Ihr schreibt eure Änderungen auf, und am Ende schaut ihr zusammen, wer was geändert hat.
• Wie iCloud es macht: iCloud schaut nur auf die Uhrzeit. „Wer hat später geschrieben? Der gewinnt!"
• Das Chaos: Wenn eure Uhren nur eine Sekunde unterschiedlich gehen (was passiert!), entscheidet iCloud willkürlich, welche Version die „wahre" ist. Die andere Version wird einfach gelöscht.
• Das Ergebnis: Du hast einen Roman geschrieben, und plötzlich ist die Hälfte davon weg, weil iCloud dachte, dein Freund habe „später" geschrieben. Oder schlimmer: Es erstellt zwei verschiedene Versionen des Romans nebeneinander, und du weißt nicht, welche die richtige ist.

3. Der Fall mit den 366 Gigabyte (Der Albtraum)

Der Autor erzählt eine wahre Geschichte: Durch normalen Gebrauch sammelte sich über Jahre hinweg ein riesiger „Müllhaufen" von 366 Gigabyte an.

• iCloud hatte Dateien an verschiedenen Orten dupliziert.
• Es hatte Dateien gelöscht, die eigentlich noch da sein sollten.
• Es hatte Versionen von Dateien erstellt, die niemand wollte.
• Warum? Weil iCloud versucht, alles in eine einzige, gerade Linie (eine Zeitlinie) zu zwängen, obwohl das Leben (und das Internet) chaotisch ist. Es ist wie ein Archivar, der versucht, alle Bücher der Welt chronologisch zu sortieren, aber ständig die Seiten durcheinanderwirft und dann behauptet: „Alles ist perfekt sortiert."

4. Warum das nicht einfach ein „Bug" ist

Apple-Ingenieure sind nicht dumm. Das Problem ist tiefer. Es ist ein Design-Fehler.
iCloud versucht, ein verteiltes System (viele Computer, die nicht immer verbunden sind) so aussehen zu lassen wie ein einzelnes System (ein Computer).

• Wenn du im Tunnel bist (kein Internet), trennt sich dein Laptop von der Cloud.
• iCloud versucht trotzdem, alles synchron zu halten, aber da es keine Verbindung gibt, macht es Annahmen.
• Wenn du wieder online bist, versucht iCloud, die Lücke zu schließen, aber es vergisst dabei oft, was wirklich passiert ist. Es „erfindet" eine Geschichte, die nicht stimmt, und löscht dabei echte Daten.

5. Die Lösung: Ein neuer Ansatz (OAE)

Der Autor schlägt vor, dass wir aufhören müssen, zu versuchen, die Cloud wie einen lokalen Ordner zu behandeln. Stattdessen brauchen wir ein System, das ehrlich ist.

• Die Idee: Stell dir vor, du tauschst ein Paket mit einem Freund. Du gibst es ihm, und er muss dir sagen: „Ich habe es sicher erhalten." Erst dann ist der Tausch fertig.
• iCloud heute: Du wirfst das Paket in die Luft und hoffst, es kommt an. Wenn es nicht ankommt, wirfst du ein neues hin, ohne zu wissen, ob das alte vielleicht doch noch unterwegs ist.
• Die Lösung (OAE): Beide Seiten müssen sich gegenseitig bestätigen. Wenn etwas unsicher ist, stoppt das System. Es macht nichts, bis es sicher ist. Es zerstört keine Daten, um Zeit zu sparen.

Zusammenfassung in einem Satz

iCloud verspricht dir einen perfekten, nahtlosen Ordner auf allen deinen Geräten, aber weil es versucht, die komplexe Realität des Internets in eine einfache, gerade Linie zu zwängen, führt es oft dazu, dass Dateien verschwinden, dupliziert werden oder Programme abstürzen – und das alles, ohne dass du es merkst, bis es zu spät ist.

Die Moral der Geschichte: Vertraue nicht blind darauf, dass deine Cloud-Dateien da sind, wo sie sein sollen, besonders wenn du mit wichtigen Tools wie Programmier-Code oder Backups arbeitest. Die Cloud ist kein magischer Speicher, sondern ein komplexer Kurierdienst, der manchmal die Pakete verwechselt.

Technische Zusammenfassung

Titel

Warum iCloud scheitert: Der Kategorienfehler der Cloud-Synchronisation und wie OAE-transaktionale Semantik ihn lösen kann
(Original: Why iCloud Fails: The Category Mistake of Cloud Synchronization, and Why OAE Transactional Semantics Can Resolve It)

Autor: Paul Borrill (DAEDAELUS)
Datum: 7. März 2026 (Version 0.7)

---

1. Das Problem: Der Kategorienfehler (Category Mistake)

Das Papier argumentiert, dass iCloud Drive kein echtes Dateisystem ist, sondern eine verteilte Verhandlungsschicht, die eine Dateisystem-Oberfläche (Facade) vortäuscht. Das fundamentale Problem ist ein Kategorienfehler: Die Projektion eines verteilten kausalen Graphen (DAG) auf eine lineare zeitliche Kette (Total Order).

• Falsche Annahmen: iCloud basiert auf „Forward-In-Time-Only" (FITO) Annahmen. Es geht davon aus, dass es eine einzige, autoritative Historie gibt und dass „später" (basierend auf Zeitstempeln) automatisch „korrekter" bedeutet.
• Verletzung von POSIX: iCloud verletzt grundlegende POSIX-Eigenschaften, die von Entwicklern und Tools (wie Git, Time Machine, Build-Systemen) erwartet werden:
  • Stabile Pfade (Pfade ändern sich je nach Sync-Status).
  • Atomare Operationen (Operationen sind über die Sync-Grenze hinweg nicht atomar).
  • Konsistente Verzeichnislisten (Listen enthalten oft „dataless files" ohne Datenblöcke).
  • Garantierte Lesbarkeit gelisteter Dateien.
• Folgen: Dies führt nicht nur zu Inkonsistenzen, sondern zu stiller Datenzerstörung. Im Gegensatz zu früheren Erkenntnissen (Parker et al., 1983), die zeigten, dass Netzwerkpartitionen Konsistenz unmöglich machen, verbirgt iCloud diese Unmöglichkeit hinter einer nahtlosen Benutzeroberfläche.

2. Methodik

Die Analyse stützt sich auf eine Kombination aus theoretischer Systemarchitektur, empirischen Beobachtungen und Fallstudien:

• Architekturanalyse: Untersuchung der macOS-Komponenten (NSFileCoordinator, fileproviderd, CloudKit/FoundationDB) und deren Interaktion mit dem lokalen Dateisystem (APFS).
• Empirische Fallstudien: Dokumentation spezifischer Fehlerereignisse, die während der normalen Nutzung über Jahre hinweg auftraten.
• Fallstudie „366 GB Archiv": Eine detaillierte Untersuchung eines Benutzers, der durch normale Nutzung 366 GB an divergenten Zuständen („iCloud Drive (Archive)") akkumuliert hatte, die sich vom Hauptzustand unterschieden. Dies erforderte manuelle MD5-basierte Vergleiche zur Wiederherstellung.
• Experimentelle Audits: Reproduzierbare Tests (z. B. in einer Linux-VM), die zeigen, wie ls Dateien auflistet, die beim anschließenden read() oder sha256sum nicht mehr verfügbar sind (On-Demand-Eviction).
• Vergleich mit Netzwerktheorie: Einbeziehung von Forschungsergebnissen der University of Waterloo zu Netzwerkpartitionen und Link-Flapping, um zu zeigen, dass das Problem systemimmanent und nicht nur ein Bug ist.

3. Schlüsselbeiträge und Erkenntnisse

A. Fünf Inkompatibilitäten

Das Papier identifiziert fünf miteinander verflochtene Inkompatibilitäten, die aus dem zentralen Kategorienfehler resultieren:

1. Inkompatibilität mit Time Machine: Time Machine erstellt Momentaufnahmen (Snapshots) eines sich ständig ändernden, verteilten Graphen. iCloud aktualisiert den lokalen Baum kontinuierlich. Dies führt zu Zirkelabhängigkeiten, unvollständigen Backups und dem Überschreiben wiederhergestellter Daten durch den Sync-Daemon.
2. Inkompatibilität mit Git: Git benötigt strikte POSIX-Semantik (Lock-Dateien, atomare rename-Operationen). iCloud behandelt Lock-Dateien als normale Dateien, synchronisiert sie und erzeugt so Konflikte. Es führt zu „Ref-Corruption" (umbenannte Branches), „Packfile-Tearing" (inkonsistente Paketdateien) und dem Verlust von Commits.
3. Inkompatibilität mit Automatisierten Toolchains: Build-Systeme und KI-Agenten (z. B. Claude Code) gehen von sofortiger Sichtbarkeit von Schreibvorgängen aus. iCloud propagiert jedoch Zwischenzustände oder evakuiert Dateien („dataless files"), was zu korrupten Builds und fehlgeschlagenen Datei-Watchern führt.
4. Das Dateisystem-Dialekt-Problem: Metadaten (Extended Attributes, Resource Forks) werden stillschweigend entfernt oder verändert. Case-Sensitivity und Pfadnormalisierung unterscheiden sich zwischen Plattformen, was zu unsichtbaren Korruptionen führt.
5. Link Flapping und Topologie-Wissen: Das Papier zieht eine Parallele zu Netzwerkproblemen. Wie bei „Link Flapping" in Netzwerken führt die Unfähigkeit, den Zustand eines Links (geliefert/nicht geliefert/unklar) bilateral zu bestätigen, zu einem epistemischen Kollaps. Das System reagiert auf Unsicherheit mit Fehlern und Retries, statt den Zustand zu pausieren.

B. Empirische Evidenz

Das Dokument listet konkrete Vorfälle auf (siehe Anhang A), darunter:

• LaTeX + Git Korruption: iCloud propagierte Zwischenzustände, was zu falschen Merge-Konflikten führte.
• Stilles Löschen: Ein gemeinsam genutzter Ordner verschwand lokal, ohne Benachrichtigung, und tauchte nach einem Neustart wieder auf (Smash-and-Restart Recovery).
• Repository-Beschlagnahmung: Der Sync-Daemon sperrte .git-Verzeichnisse sofort nach der Erstellung, sodass keine Operationen mehr möglich waren („Operation not permitted").
• Dateinamen-Korruption: iCloud fügte zufällige 6-stellige Präfixe zu Dateinamen hinzu, um Konflikte zu lösen, was semantische Identifikatoren zerstörte.

C. Die Lösung: Open Atomic Ethernet (OAE)

Das Papier schlägt Open Atomic Ethernet (OAE) als strukturelle Lösung vor, die auf physikalischer Realität basiert:

• Bilaterale Transaktionen: Beide Seiten eines Links halten identische Zustandsmaschinen. Ein Transfer gilt erst als real, wenn er explizit vom Empfänger bestätigt wurde.
• Symmetrische Reversibilität: Jede Operation hat eine logische Umkehrung. Bei Unsicherheit wird der Zustand zurückgesetzt, nicht korrupt weitergeschaltet.
• Erhaltung von Informationen (Conservation Principle): Informationen werden nicht zerstört (wie bei „Last-Writer-Wins"), sondern konserviert. Konflikte werden semantisch gelöst, nicht durch Zeitstempel arbitriert.
• Triangle Topology: Statt einer zentralen Cloud-Server-Architektur (Switched Network) wird ein Mesh aus direkten Links vorgeschlagen, das durch Dreiecks-Topologien (3 Knoten) lokale Failover-Mechanismen ohne Timeout-and-Retry ermöglicht.

4. Ergebnisse

• Bestätigung der Katastrophe: Die Analyse zeigt, dass die Fehler von iCloud keine zufälligen Bugs sind, sondern vorhersehbare Konsequenzen eines fehlerhaften Protokoll-Designs (FITO).
• Skalierbarkeit des Problems: Ein Fallbeispiel zeigte, dass normale Nutzung über Jahre zu hunderten Gigabyte an nicht auflösbarer Divergenz, stillen Löschungen und Phantom-Duplikaten führt.
• Unmöglichkeit der Korrektur durch Overlay: Lösungen, die über dem Link-Layer operieren (Overlay-Netzwerke), können das fundamentale Problem der kausalen Unsicherheit nicht lösen. Die Lösung muss auf der Ebene der bilateralen Zustandsbestätigung (L2) liegen.

5. Bedeutung

Das Papier hat weitreichende Implikationen für das Design verteilter Systeme:

• Paradigmenwechsel: Es fordert einen Wechsel von „Event-History" (Zeitstempel) zu „Invarianten-Erhaltung" (Zustandserhaltung) als Grundlage für Synchronisation.
• Kritik an Cloud-Paradigmen: Es entlarvt die Marketing-Versprechen von „nahtloser Synchronisation" als physikalisch unmöglich unter den gegebenen Bedingungen (Netzwerkpartitionen, intermittierende Verbindung).
• Architektonische Vision: Es bietet einen konkreten Weg (OAE), wie Synchronisation physikalisch korrekt implementiert werden kann, indem sie Unsicherheit als Zustand behandelt, der den Fortschritt pausiert, statt den Zustand zu korrumpieren.
• Warnung für Entwickler: Es warnt eindringlich davor, Cloud-Speicher (insbesondere iCloud Drive) für Versionierungssysteme (Git), Build-Prozesse oder Datenbanken zu verwenden, da diese die POSIX-Verträge verletzen, auf denen sie basieren.

Fazit: iCloud scheitert, weil es versucht, ein physikalisches Problem (verteilte Konsistenz unter Partitionierung) durch eine Abstraktion (Dateisystem-Facade) zu lösen, die die zugrundeliegende Komplexität verschleiert. Die Lösung liegt nicht in besseren Algorithmen für das bestehende Modell, sondern in einer grundlegenden Neugestaltung der Protokoll-Semantik hin zu bilateralen, reversiblen und informationserhaltenden Transaktionen.