Why iCloud Fails: The Category Mistake of Cloud Synchronization

Dit paper betoogt dat iCloud Drive faalt door een fundamentele categoriefout waarbij een gedistribueerd causaal grafiek ten onrechte wordt geprojecteerd op een lineaire tijdslijn, wat leidt tot data-corruptie in ontwikkelaarswerkflows en dat soortgelijke epistemische ineenstorting in netwerken kan worden opgelost door de transactionele semantiek van Open Atomic Ethernet.

De kern

De Grote Misverstand: iCloud is geen "Wolk", maar een "Illusie"

Stel je voor dat je een magische koffer hebt. Als je een foto in de koffer doet, verschijnt die foto direct in een identieke koffer bij je vriend in het buitenland. Je denkt: "Geweldig, dit is een perfecte kopieer-machine!"

Maar volgens Paul Borrill (de auteur van dit paper) is iCloud Drive geen magische koffer. Het is meer als een dromerige verteller die je vertelt wat er in de koffer zit, terwijl hij soms zelf niet weet wat er echt in zit.

Het paper stelt dat iCloud een fundamentele fout maakt: het doet alsof het een gewone, lokale opslagplek is (zoals een harde schijf), terwijl het in werkelijkheid een drukte netwerk is waar dingen soms vastlopen, verdwijnen of dubbel worden.

Hier zijn de belangrijkste punten, vertaald naar alledaagse beelden:

1. De "Vooruit in de Tijd"-Fout (FITO)

Stel je voor dat je een brief schrijft en die per post verstuurt. iCloud werkt alsof het alleen maar naar voren kijkt. Het denkt: "Als ik de brief later heb ontvangen dan de vorige, dan is mijn versie de juiste."

• Het probleem: In de echte wereld (en in computers) gebeurt alles niet in één rechte lijn. Soms komen twee brieven tegelijk aan, of verdwijnt er een onderweg.
• De iCloud-methode: Als twee mensen tegelijk een bestand wijzigen, kiest iCloud willekeurig de versie met de "laatste tijdstempel" en wist de andere versie. Het doet alsof de andere versie nooit heeft bestaan.
• Het gevolg: Je kunt je werk kwijtraken zonder dat je het merkt. Het systeem zegt: "Geen probleem, alles is gesynchroniseerd!" terwijl er eigenlijk een gat in je werk zit.

2. De "Spookbestanden" (Dataless Files)

In de nieuwere versies van macOS (Sonoma en nieuwer) gebruikt iCloud een trucje om ruimte te besparen. Het laat een lijst zien met al je bestanden, maar de inhoud is soms nog niet op je computer geladen.

• De Analogie: Stel je voor dat je een bibliotheek hebt. De catalogus (de lijst op je scherm) zegt: "Hier staat boek X, het is 500 pagina's dik." Maar als je het boek van het plankje haalt om te lezen, is het leeg. De bladzijden zijn nog niet gedrukt.
• Het gevaar: Als je een computerprogramma (zoals Git of een AI-tool) probeert te gebruiken, denkt het: "Ik heb het bestand, ik ga het bewerken." Maar omdat het bestand leeg is, crasht het programma of maakt het een fout. iCloud zegt: "Het bestand is er!" (want het staat in de catalogus), maar het is er niet echt.

3. De Strijd met Time Machine en Git

• Time Machine (Je tijdmachine): Time Machine wil een foto maken van je hele computer op één specifiek moment. Maar iCloud is continu aan het veranderen, bestanden verplaatsen en laden.
  • Analogie: Het is alsof je een foto wilt maken van een dansende ballerina, maar ze blijft dansen terwijl je de knop indrukt. De foto wordt wazig, of Time Machine raakt in de war en slaat niets op.
• Git (De versiegeschiedenis voor programmeurs): Git werkt met "slotjes". Als iemand aan een bestand werkt, zet hij een slotje op. iCloud ziet dit slotje als een gewoon bestandje en sturen het naar je andere computer.
  • Analogie: Je laat je sleutel in het slot van je huis zitten. Je vriend in het buitenland krijgt een kopie van die sleutel en probeert ook je huis binnen te komen. Nu zit er een sleutel in het slot van jouw huis én in het slot van zijn huis. Niemand kan meer binnen. Je project is vastgelopen.

4. De 366 GB Chaos

De auteur beschrijft een echt voorbeeld waar hij jarenlang iCloud heeft gebruikt. Het resultaat? Een enorme rommelpost van 366 GB aan dubbele bestanden, bestanden die verdwenen waren, en bestanden die er anders uitzagen dan op de andere computer.

• Hij moest maandenlang handmatig bestanden vergelijken (met een "vingerafdruk" van elk bestand) om te zien wat echt was en wat iCloud had verpest. Het systeem had beloofd dat alles "perfect" zou zijn, maar had in plaats daarvan een dubbelzinnige nachtmerrie gecreëerd.

5. Waarom gebeurt dit? (De "Categoriefout")

De kern van het probleem is dat Apple probeert een drukte, chaotisch netwerk (waar bestanden soms vastlopen of vertraagd zijn) te vermommen als een rustige, lokale kast.

• Het is alsof je probeert een vliegtuig te besturen met de handleiding van een fiets. De fiets-handleiding zegt: "Pedaal om te gaan." Maar in een vliegtuig (het netwerk) betekent "pedalen" soms dat je neerstort als er een storm is.
• iCloud probeert de storm te negeren en doet alsof het altijd rustig is. Dat werkt niet.

6. De Oplossing: OAE (Open Atomic Ethernet)

De auteur stelt een nieuwe manier voor om netwerken te bouwen, genaamd OAE.

• De Analogie: In plaats van dat je een brief verstuurt en hoopt dat hij aankomt (en dan hoopt dat de ontvanger het goed heeft), moet je eerst bevestigen dat de ontvanger de brief heeft ontvangen en gelezen, voordat je de volgende stap zet.
• Als er twijfel is (bijvoorbeeld: "Is de brief wel aangekomen?"), stopt het systeem. Het gaat niet door met werken. Het wacht tot de twijfel weg is.
• Dit voorkomt dat bestanden "halfaf" worden opgeslagen of dat er dubbele versies ontstaan. Het is een systeem dat eerlijk is over wat er gebeurt, in plaats van dat het doet alsof alles perfect is.

Conclusie voor de Gemiddelde Gebruiker

iCloud is handig voor simpele dingen (zoals je foto's delen met je gezin), maar het is geen betrouwbare plek voor:

• Belangrijke werkbestanden die je niet wilt verliezen.
• Programmeerwerk (Git).
• Complexe projecten waar bestanden vaak veranderen.

Het paper waarschuwt: Vertrouw niet blindelings op de "magie" van de cloud. Als je iCloud gebruikt voor serieuze dingen, moet je weten dat het systeem soms zelf beslissingen neemt die je werk kunnen vernietigen, en dat het je daar vaak niets over vertelt.

De boodschap is simpel: iCloud is een "vertrouwde" vriend die soms liegt om je niet te kwetsen, maar in de digitale wereld is die leugen dodelijk voor je data.

Technische samenvatting

Titel: Waarom iCloud Faalt: De Categoriefout van Cloudsynchronisatie en hoe OAE-transactiesemantiek dit kan oplossen

Auteur: Paul Borrill (DAEDAELUS)
Versie: 0.7 (7 maart 2026)

---

1. Het Probleem: De Categoriefout

Het paper stelt dat iCloud Drive fundamenteel faalt wanneer het wordt gebruikt in combinatie met tools die POSIX-bestandssysteemsemantiek veronderstellen (zoals Time Machine, Git, geautomatiseerde toolchains en AI-coders). De kern van het probleem is geen implementatiefout, maar een categoriefout (Category Mistake).

• De Valse Belofte: iCloud presenteert zich als een transparante extensie van het lokale bestandssysteem (POSIX-compliant), maar werkt in werkelijkheid als een gedistribueerd onderhandelingsysteem.
• De Categoriefout: Het projecteren van een gedistribueerde causale graf (waar gebeurtenissen in een deeltijdse orde plaatsvinden) op een lineaire tijdslijn (een totale orde). iCloud probeert een complexe, niet-lineaire geschiedenis van wijzigingen over meerdere apparaten te reduceren tot één enkele "waarheid" gebaseerd op tijdstempels.
• Gevolg: Deze projectie vernietigt essentiële informatie over concurrentie, conflicten en oorsprong. Het systeem behandelt onzekerheid als een fout en lost deze op door data te overschrijven, te dupliceren of stilzwijgend te verwijderen, in plaats van de onzekerheid te erkennen en te managen.

2. Methodologie en Bewijslast

De auteur gebruikt een combinatie van theoretische analyse, architecturale dissectie en empirisch bewijs om de stellingen te onderbouwen:

• Theoretische Basis: De paper bouwt voort op het werk van Parker et al. (1983), dat aantoont dat netwerkpulvering (network partitioning) wederzijdse consistentie onmogelijk maakt. iCloud verbergt deze onmogelijkheid achter een gebruikersinterface die "naadloosheid" belooft.
• Architecturale Analyse: Een diepgaande inspectie van de iCloud-architectuur, inclusief de fileproviderd-daemon, NSFileCoordinator, en het gebruik van "dataless files" (bestanden met alleen metadata, geen data-extents) in macOS Sonoma.
• Empirisch Bewijs:
  • Gedocumenteerde corruptie: Specifieke incidenten waarbij Git-repositories onbruikbaar werden, Time Machine-backups faalden, en bestanden corrupt raakten.
  • Case Study: Een analyse van een 366 GB "iCloud Drive (Archive)" map die ontstond door jarenlang normaal gebruik. Deze map bevatte 110 items die divergeren van de primaire map, met duizenden bestanden die stilzwijgend waren verwijderd of gedupliceerd.
  • Netwerkstudies: Referentie naar studies van de Universiteit van Waterloo (Alquraan et al.) die aantonen dat 90% van de storingen in gedistribueerde systemen door netwerkpulvering "stil" (silent) is en leidt tot dataverlies.

3. Belangrijkste Incompatibiliteiten

Het paper identificeert vijf onderling verbonden incompatibiliteiten die voortvloeien uit de categoriefout:

1. Incompatibiliteit met Time Machine: Time Machine maakt momentopnames (snapshots) van een bestandssysteem dat continu verandert door de sync-daemon. Dit leidt tot een circulaire afhankelijkheid: Time Machine vereist een stabiele staat, maar iCloud verandert de staat continu. Restauraties worden overschreven door de sync-daemon.
2. Incompatibiliteit met Git: Git vertrouwt op atomische bestandsoperaties (zoals lock-files en rename-sequenties). iCloud synchroniseert bestanden individueel en kan lock-files (index.lock) naar andere apparaten repliceren, waardoor Git denkt dat een ander proces het repository bezet. Ook leidt het tot "packfile tearing" (inconsistente pakketbestanden) en corrupte refs.
3. Incompatibiliteit met Geautomatiseerde Toolchains: Scripts en AI-agenten die bestanden schrijven en lezen, worden geconfronteerd met "dataless files". Een tool kan een bestand zien (ls of stat slaagt), maar bij het lezen (read) wordt een netwerkopvraag geactiveerd die kan time-outen of verouderde data kan leveren.
4. Het "Filesystem Dialect" Probleem: iCloud stript metagegevens (zoals extended attributes en resource forks) en behandelt bestandsnamen als veranderbare metadata. Dit leidt tot stilzwijgende corruptie van bestandsnamen en metadata-invarianten.
5. Forward-In-Time-Only (FITO) Semantiek: Het protocol maakt alleen "voorwaartse" stappen. Het kan geen reversibele transacties uitvoeren. Als een conflict optreedt, kiest het systeem voor "Last-Writer-Wins" op basis van klok-tijdstempels, wat in een gedistribueerde omgeving met klok-drift onbetrouwbaar is.

4. Resultaten en Observaties

De analyse leidt tot de volgende concrete bevindingen:

• Stille Datavernietiging: iCloud verwijdert bestanden of mappen lokaal zonder waarschuwing als er conflicten zijn, terwijl ze op de server nog bestaan (en vice versa).
• De "366 GB" Divergentie: In de case study bleek dat iCloud door normaal gebruik een enorme hoeveelheid dubbele en divergente data had gegenereerd die niet automatisch te reconciliëren was.
• Epistemische Ineenstorting: Net als bij "link flapping" in netwerken, verliest iCloud de kennis van de topologie. Het systeem kan niet bepalen welke versie van een bestand de juiste is, en lost dit op door willekeurige keuzes te maken (bijv. nummering van bestandsnamen: file.txt vs file 2.txt).
• Onoplosbare Racecondities: De interactie tussen de sync-daemon en applicaties creëert racecondities waarbij applicaties onvolledige bestandsstaten ontvangen of blokkeren door exclusieve locks van de daemon.

5. De Oplossing: Open Atomic Ethernet (OAE)

De auteur stelt dat iCloud niet "gefixt" kan worden binnen het huidige paradigma, omdat de fout fundamenteel in de architectuur zit. De voorgestelde oplossing is Open Atomic Ethernet (OAE), een transactiesemantiek gebaseerd op fysieke realiteit:

• Bilaterale Transacties: In plaats van een master/slave-model, hebben beide kanten van een link een identieke staatmachine. Een transfer is pas echt als deze expliciet is bevestigd door de ontvanger en teruggekoppeld naar de zender.
• Reversibiliteit: Elke operatie heeft een logische inverse. Bij onzekerheid (bijv. netwerkpulvering) wordt de operatie niet voortgezet of overschreven, maar teruggedraaid naar een bekende goede staat.
• Behoud van Informatie: Geen enkele token (data) gaat verloren; hij wordt ofwel geleverd of expliciet afgewezen. Dit voorkomt dat conflicten worden opgelost door data te vernietigen.
• Driehoekstopologie: Om netwerkpulvering te overwinnen, stelt OAE een driehoeksstructuur voor (minimaal drie knooppunten verbonden via directe links). Als één link faalt, kunnen de andere twee de staat coördineren via een transactionele manager (TM), zonder timeout-and-retry cycli.
• Toepassing op iCloud: De auteur pleit ervoor om iCloud te transformeren van een "eventually consistent" cloud-relay naar een lokaal mesh-netwerk met bilaterale transacties, waarbij de cloud slechts dient als back-up en niet als de primaire autoriteit voor synchronisatie.

6. Betekenis en Conclusie

Het paper concludeert dat de problemen met iCloud niet toevallige bugs zijn, maar voorspelbare gevolgen van het toepassen van FITO-annames op een complex, gedistribueerd systeem.

• Kernboodschap: Cloudsynchronisatie kan niet worden gemodelleerd als een lokaal bestandssysteem. Het vereist een nieuwe semantiek die onzekerheid erkent en behoudt in plaats van deze te maskeren.
• Implicatie: Zolang systemen proberen "naadloze" synchronisatie te bieden door de complexiteit van gedistribueerde causaliteit te verbergen, zullen ze blijven falen met stille dataverlies en corruptie.
• Toekomstvisie: De oplossing ligt in het aligneren van protocolgedrag met de fysieke realiteit van netwerken (via OAE), waarbij onzekerheid progressie pauzeert in plaats van staat te corrumperen.

Dit document fungeert als een krachtige kritiek op de huidige staat van cloud-opslag en biedt een theoretisch kader voor hoe toekomstige systemen robuuster kunnen worden ontworpen door causale relaties te respecteren in plaats van ze te reduceren tot een lineaire tijdlijn.