Warum entstehen Nextcloud-Synchronisationskonflikte und wie löse ich Sperren und Konfliktdateien ohne Datenverlust?

So arbeitet die Nextcloud-Synchronisation: Abgleichlogik, Änderungsstände, Upload- und Download-Reihenfolge

Die Nextcloud-Synchronisation zwischen Desktop-Client und Server folgt einer klaren Abgleichlogik: Lokale Änderungen werden erkannt, in einen konsistenten Upload übersetzt und anschließend mit dem Serverzustand abgeglichen. Parallel dazu werden Serveränderungen heruntergeladen und lokal umgesetzt. Entscheidend ist dabei, dass nicht „Dateien“ als Ganzes verglichen werden, sondern Zustände: Metadaten, Änderungszeitpunkte, ETags und Versionsinformationen steuern, ob eine Datei als unverändert gilt oder als neue Revision hoch- beziehungsweise heruntergeladen werden muss.

Die Reihenfolge von Upload und Download wirkt im Alltag häufig wie „gleichzeitig“, tatsächlich arbeitet der Client in Zyklen. Er sammelt Ereignisse (Datei erstellt, geändert, gelöscht, umbenannt), bewertet sie gegen den letzten bekannten Serverzustand und führt dann planbar viele Operationen aus. Netzwerkunterbrechungen, parallele Zugriffe und große Dateimengen verschieben diese Zyklen, wodurch Konflikte nicht zufällig, sondern als Folge widersprüchlicher Zustandsfortschreibungen entstehen.

Abgleichlogik: Was der Client tatsächlich vergleicht

Beim Start und in regelmäßigen Intervallen führt der Desktop-Client einen Remote-Abgleich durch. Er liest Verzeichnislisten und Metadaten vom Server und vergleicht diese mit der lokalen Synchronisationsdatenbank. Als Grundlage dienen WebDAV-Informationen wie ETag (Inhaltskennung), Größenangaben und Zeitstempel; zusätzlich werden serverseitige Eigenschaften herangezogen, die den aktuellen Zustand einer Ressource repräsentieren. Eine lokale Datei gilt erst dann als „hochzuladen“, wenn der Client eine Abweichung zwischen lokalem Zustand und zuletzt bestätigtem Serverzustand feststellt.

Für lokale Änderungen überwacht der Client das Dateisystem über Betriebssystemmechanismen (unter Windows etwa über Change Notifications, unter Linux über inotify). Diese Events sind nicht identisch mit „fertigen“ Dateioperationen: Beim Speichern großer Dateien können viele Teiländerungen auftreten. Der Client bündelt solche Ereignisse und startet Uploads erst, wenn die Datei für einen kurzen Zeitraum stabil erscheint oder wenn die Anwendung den Schreibvorgang abgeschlossen hat. Bei häufigen In-Place-Updates (z. B. Datenbankdateien, PST/OST, virtuelle Disks) kommt es dadurch eher zu Überschneidungen mit gleichzeitigen Serveränderungen.

Änderungsstände: Lokale Datenbank, Journal und „zuletzt bestätigter“ Zustand

Der Client führt intern Buch über den letzten erfolgreichen Abgleich, typischerweise in einer lokalen Datenbank. Dort liegt nicht der Dateiinhalt, sondern der zuletzt bestätigte Zustand: Pfad, Größe, Zeitstempel und die serverseitige Kennung (z. B. ETag). Daraus folgt eine wichtige Eigenschaft: Eine Datei kann lokal verändert sein, ohne sofort hochgeladen zu werden, wenn der Client sie noch als „in Bearbeitung“ einstuft oder wenn Uploads durch Regeln (Pause, Bandbreitenlimit, Netzwerkstatus) verzögert werden.

Änderungen werden außerdem als Aufgaben (Jobs) in eine Warteschlange übertragen. Diese Warteschlange stellt sicher, dass Abhängigkeiten eingehalten werden: Ein Ordner muss existieren, bevor Dateien in ihn hochgeladen werden; ein Rename muss konsistent mit nachfolgenden Uploads bleiben; ein Löschen darf nicht vor einem noch offenen Upload ausgeführt werden. Bricht eine Verbindung ab, bleibt der Job erhalten und wird später fortgesetzt. Daraus entsteht eine zeitliche Entkopplung zwischen „Datei wurde gespeichert“ und „Server kennt die neue Revision“.

Upload- und Download-Reihenfolge: Warum die Reihenfolge variiert

Die intuitive Vorstellung einer festen Reihenfolge („erst Upload, dann Download“ oder umgekehrt) trifft nur eingeschränkt zu. Der Client priorisiert je nach Situation: Lokale Änderungen werden bevorzugt hochgeladen, um den eigenen Zustand zu veröffentlichen; gleichzeitig müssen Serveränderungen zeitnah heruntergeladen werden, um die lokale Sicht zu aktualisieren. In der Praxis laufen beide Richtungen parallel in getrennten Operationen, allerdings mit koordinierter Fehlerbehandlung, damit derselbe Pfad nicht gleichzeitig in widersprüchlichen Zuständen verarbeitet wird.

Besonders sichtbar wird diese Logik bei Ordnerstrukturen und Umbenennungen. Wird lokal ein Ordner umbenannt, müssen darunterliegende Dateien in der Warteschlange neu referenziert werden. Kommt in dieser Phase eine Serveränderung an derselben Stelle hinzu, kann der Client zwar beide Richtungen korrekt abarbeiten, muss aber streng nach Metadaten entscheiden, welche Operation den „aktuellen“ Pfad darstellt. Je größer der Abstand zwischen lokaler Aktion und bestätigtem Serverzustand, desto höher ist die Wahrscheinlichkeit, dass eine zweite Instanz (anderes Gerät, Weboberfläche) zwischenzeitlich denselben Pfad verändert.

• Ordner zuerst: Neue Ordner werden vor enthaltenen Dateien synchronisiert, damit Uploads nicht an fehlenden Zielpfaden scheitern.
• Renames als eigene Operation: Umbenennungen und Verschiebungen haben Priorität, weil nachfolgende Uploads sonst auf veraltete Pfade zeigen würden.
• Große Dateien in Blöcken: Uploads großer Dateien laufen oft als Chunk-Upload; der Server sieht den finalen neuen Stand erst nach dem Commit, wodurch ein Zeitfenster für konkurrierende Änderungen entsteht.
• Serveränderungen mit hohem Aktualitätswert: Änderungen, die serverseitig als neuer Zustand erkannt werden, lösen einen Download aus, auch wenn lokale Uploads noch in der Warteschlange stehen.

Typische Zeitfenster für widersprüchliche Zustände

Konfliktträchtige Situationen entstehen weniger durch „Fehler“ als durch überlappende Zeitfenster. Dazu zählt der Zeitraum zwischen lokalem Speichern und erfolgreichem Upload, ebenso der Zeitraum zwischen serverseitiger Änderung und dem nächsten Remote-Abgleich. Wenn in beiden Fenstern dieselbe Datei unabhängig voneinander verändert wird, besitzt der Client zwei plausible Wahrheiten: lokal existiert ein neuer Inhalt, serverseitig existiert ebenfalls ein neuer Inhalt. Ohne zusätzliche Koordination kann der Client nicht entscheiden, welcher Inhalt der „richtige“ ist, und muss beide Stände erhalten.

Auch scheinbar banale Details beeinflussen diese Fenster: Energiesparzustände unterbrechen den Upload, VPN-Wechsel führen zu neuen Sessions, und Anwendungen schreiben Dateien nicht atomar, sondern in mehreren Schritten. Dazu kommt die Besonderheit, dass Zeitstempel zwischen Dateisystemen und Server nicht immer identisch aufgelöst werden. Deshalb verlässt sich die Entscheidung über „neu“ und „alt“ nicht ausschließlich auf mtime, sondern auf eine Kombination aus Metadaten und bestätigten Zustandsmarkern.

Aus Anwendersicht lässt sich die Abgleichlogik am zuverlässigsten verstehen, wenn jede Änderung als eigener, bestätigungspflichtiger Zustand betrachtet wird. Erst wenn der Client einen Upload vollständig abgeschlossen und den neuen Serverzustand zurückgemeldet bekommen hat, gilt diese Revision als synchron. Bis dahin bleibt jede weitere Bearbeitung ein Kandidat für Überschneidungen mit externen Änderungen, insbesondere bei paralleler Bearbeitung auf mehreren Geräten.

Konflikte und Sperren verstehen und erkennen: typische Auslöser, Locking-Mechanismen, Indikatoren in Client und Weboberfläche

Bei der Nextcloud-Synchronisation entstehen Probleme selten „zufällig“. Konflikte und Sperren folgen meist klaren Regeln: Der Desktop- oder Mobile-Client vergleicht lokale Änderungen mit dem Serverzustand, überträgt Deltas und reagiert auf konkurrierende Bearbeitungen. Treffen zeitgleich verschiedene Dateistände aufeinander oder blockiert ein Lock einen Schreibvorgang, zeigt sich das in Form von Konfliktdateien, abgebrochenen Uploads oder wiederholten Retry-Schleifen. Für eine saubere Diagnose lohnt es sich, typische Auslöser, das Locking-Modell und die sichtbaren Indikatoren getrennt zu betrachten.

Typische Auslöser für Synchronisationskonflikte

Konflikte entstehen, wenn dieselbe Datei auf mindestens zwei Seiten verändert wird, bevor eine Seite den aktuellen Stand der anderen übernommen hat. Relevant ist dabei nicht nur „gleichzeitig“, sondern auch „ohne Kenntnis des aktuellen Stands“. Offline-Phasen, instabile Verbindungen, aggressive Energiesparmodi oder große Dateien mit langer Upload-Zeit vergrößern das Zeitfenster, in dem konkurrierende Änderungen auftreten können.

Besonders anfällig sind Formate, die nicht „merge-fähig“ sind: Office-Dokumente, Datenbanken, Archive oder proprietäre Projektdateien. Zusätzlich wirken Dateisystem- und Anwendungsdetails hinein, etwa das Schreiben über temporäre Dateien, „Safe Save“-Mechanismen (erst ~$ bzw. .tmp, dann Rename) oder häufige Auto-Saves, die viele Versionen und Uploads erzeugen.

• Parallelbearbeitung auf mehreren Geräten: Eine Datei wird auf Gerät A geändert, während Gerät B noch den alten Stand geöffnet hat und später speichert.
• Offline-Änderungen: Client arbeitet ohne Verbindung weiter; beim Wiederverbinden kollidieren lokale Änderungen mit bereits hochgeladenen Serveränderungen.
• Instabile Netze und abgebrochene Transfers: Uploads werden wiederholt neu angesetzt; zwischendurch entstehen weitere Änderungen an derselben Datei.
• „Safe Save“ und temporäre Dateien: Anwendungen speichern über rename()-Muster; der Client sieht eine Lösch- und Ersetzsequenz statt „Bearbeitung“, was Timing-Probleme verschärfen kann.
• Große Dateien und lange Bearbeitungsfenster: Während ein großer Upload läuft, wird die Datei erneut geändert; die Serverversion und die lokale Version driften auseinander.

Locking-Mechanismen: Was gesperrt wird und warum

Nextcloud nutzt Sperren (Locks), um Inkonsistenzen zu verhindern, wenn mehrere Prozesse dieselben Dateien oder Ordnerstrukturen verändern. In der Praxis treten Sperren vor allem in zwei Kontexten auf: beim Schreiben von Datei-Inhalten (Upload, Chunking, Abschluss eines Uploads) sowie bei Metadaten-Operationen (Verschieben, Umbenennen, Löschen). Sperren sind grundsätzlich temporär; problematisch werden sie, wenn ein Prozess unerwartet endet oder ein Backend (Datenbank, Cache) nicht konsistent arbeitet.

Wichtig ist die Unterscheidung: Ein Konflikt ist eine inhaltliche Kollision von Versionen. Eine Sperre ist eine technische Blockade, die einen Vorgang verhindert, bis ein anderer Vorgang beendet ist. Eine Sperre kann indirekt Konflikte begünstigen, weil Clients bei wiederholten Fehlversuchen länger mit veralteten Ständen arbeiten. Umgekehrt kann eine Konfliktauflösung scheitern, wenn ein Lock auf dem Zielpfad hängt.

Indikatoren im Desktop-Client: Status, Benachrichtigungen, Protokolle

Der Desktop-Client liefert mehrere Ebenen an Signalen. Auf oberster Ebene stehen Synchronisationsstatus und Badge-Icons (z. B. Fehler, Pause, laufender Transfer). Aussagekräftiger sind detailierte Einträge zu einzelnen Dateien: Dort zeigt sich, ob es sich um einen Konflikt (zusätzliche Datei mit Konfliktmarker), um eine Blockade durch Locking („gesperrt“) oder um wiederholte Netzfehler handelt. Wiederkehrende Muster sind wichtiger als einzelne Meldungen; ein sporadischer HTTP-Fehler wirkt anders als ein permanentes „locked“ auf derselben Datei.

Für die Einordnung hilft die Unterscheidung nach Richtung: „Upload kann nicht abgeschlossen werden“ deutet eher auf Serverzustand/Locks, während „lokale Datei weicht ab“ bzw. eine neu angelegte Konfliktkopie auf konkurrierende Änderungen hinweist. Wenn Konflikte auf vielen Dateien gleichzeitig auftreten, liegt häufig ein externer Prozess zugrunde (z. B. Batch-Editor, Virenscanner, Backup-Tool im Sync-Ordner), der Dateien in kurzer Folge anfasst.

• Statusansicht pro Datei prüfen: Konfliktdateien sind meist als zusätzliche Datei mit Konfliktzusatz sichtbar; Sperrprobleme erscheinen als „kann nicht synchronisieren“ mit Hinweis auf „locked“/„gesperrt“.
• Wiederholte Retries erkennen: Häufen sich Einträge mit gleicher Datei und ähnlichem Zeitstempel, liegt eher ein persistentes Hindernis (Lock, Berechtigung, Pfadproblem) vor als ein transienter Netzfehler.
• Lokale Nebenverursacher ausschließen: Prozesse, die den Sync-Ordner scannen oder umschreiben, erzeugen typische Muster (kurze Änderungsabstände, viele Rename-Events); Indizien sind Dateinamen wie ~$Datei.docx oder .tmp im selben Ordner.
• Client-Log gezielt filtern: Für zeitliche Korrelation sind Log-Ausschnitte um den Fehlerzeitpunkt relevant; Suchbegriffe sind häufig conflict, locked, 412, 423 oder Etag.

Indikatoren in der Weboberfläche: Aktivität, Dateidetails, Sperrhinweise

In der Weboberfläche lassen sich Konflikte nicht immer als „Konflikt“ etikettiert erkennen, wohl aber indirekt. Die Aktivitätsansicht zeigt, ob kurz nacheinander mehrere Änderungen an derselben Datei eingegangen sind und von welchen Clients. In den Dateidetails sind Zeitstempel, Größe und teils auch die Änderungsquelle hilfreich, um zu sehen, ob der Serverstand plausibel zur lokalen Erwartung passt. Bei Sperrproblemen fallen eher wiederholte, nicht fortschreitende Upload-Versuche auf, ohne dass sich der Serverstand aktualisiert.

Locking zeigt sich in der Oberfläche je nach Kontext: als fehlgeschlagene Uploads, gelegentlich als Hinweis auf gesperrte Ressourcen, oder als „hängt“ wirkende Aktionen (z. B. Umbenennen bleibt stehen). Entscheidend ist die Trennung von Ursache und Folge: Ein in der Oberfläche sichtbarer, aktueller Dateistand schließt lokale Konflikte nicht aus, wenn lokal parallel gearbeitet wurde. Umgekehrt kann ein veralteter Serverstand schlicht bedeuten, dass ein Client den Upload noch nicht finalisieren konnte.

• Aktivität zu einer Datei prüfen: Nahe beieinander liegende Einträge „geändert“ von unterschiedlichen Geräten sind ein starkes Konfliktsignal, besonders bei binären Formaten.
• Dateidetails gegen lokale Datei abgleichen: Größe und Änderungszeit im Server können helfen, eine „falsche“ lokale Version zu entlarven, wenn das lokale Dateisystem einen späteren Zeitstempel trägt, der Upload aber nie abgeschlossen wurde.
• Serien von Fehlversuchen erkennen: Wiederholt scheiternde Uploads ohne sichtbare Aktualisierung sprechen eher für Locking/Berechtigungen als für einen echten Konflikt.
• Gemeinsame Bearbeitung (Office) berücksichtigen: Bei kollaborativer Bearbeitung im Browser gelten andere Konfliktmuster als beim lokalen Speichern; Konflikte entstehen dann häufiger durch paralleles lokales Öffnen derselben Datei und spätes Zurückspeichern.

Konflikte sauber auflösen und Versionen absichern: pragmatische Schrittfolgen, Prüfstellen auf Client/Server, Vorbeugung bei Mehrgeräte-Nutzung

Pragmatische Schrittfolge zur Konfliktauflösung ohne Datenverlust

Konflikte entstehen typischerweise dann, wenn derselbe Pfad auf mindestens zwei Geräten verändert wird, ohne dass eine Seite den zwischenzeitlichen Stand der anderen gesehen hat. Der Nextcloud-Desktop-Client und mobile Clients versuchen, inkonsistente Zustände zu vermeiden, indem sie geänderte Inhalte nicht stillschweigend überschreiben. Stattdessen werden Konfliktkopien erzeugt oder Uploads/Downloads verzögert, bis eindeutige Bedingungen vorliegen.

Für eine saubere Auflösung zählt die Reihenfolge: zuerst das „Einfrieren“ des Zustands, dann das Sammeln aller Varianten, anschließend das Vergleichen und erst danach das Zusammenführen. Besonders bei Office-Dateien, Datenbanken, Passwort-Tresoren oder Notiz-Backends (z. B. SQLite) führt jedes vorschnelle „Überschreiben“ zu schwer nachvollziehbaren Teilverlusten.

• Synchronisation stoppen: Betroffene Synchronisationsverbindung im Desktop-Client auf „pausiert“ setzen bzw. mobile Synchronisation deaktivieren, um weitere Schreibvorgänge zu verhindern.
• Alle Varianten sichern: Konfliktdateien, lokale Kopien und Serverstände in ein separates Verzeichnis kopieren; in Zweifelsfällen zusätzlich den Ordner …/Nextcloud (lokaler Sync-Stamm) unverändert belassen und nur Kopien bearbeiten.
• Konfliktdateien identifizieren: Dateinamen mit Konfliktsuffix (je nach Client-Format) sowie abweichende Änderungszeiten prüfen; bei Bedarf gezielt nach Mustern wie *conflict* oder *Konflikt*
• Inhaltlich vergleichen: Für Text/Code diff-fähige Werkzeuge verwenden; für Office-Dokumente die integrierten Vergleichsfunktionen nutzen oder in ein neutrales Format exportieren, bevor zusammengeführt wird.
• „Gewinnerdatei“ festlegen und zusammenführen: Eine Datei wird als Zielstand bestimmt; Inhalte aus den anderen Varianten werden kontrolliert eingearbeitet. Erst danach wird die Zieldatei im Sync-Ordner ersetzt bzw. gespeichert.
• Sync geordnet wieder anfahren: Zuerst nur ein Gerät aktivieren und den vollständigen Abgleich abwarten; anschließend Geräte nacheinander zuschalten. So bleibt nachvollziehbar, welche Änderung welchen Upload auslöst.

Prüfstellen auf Client-Seite: typische Ursachen und belastbare Indikatoren

Viele Konflikte lassen sich auf wenige Muster zurückführen: gleichzeitiges Bearbeiten auf mehreren Geräten, instabile Netze, Sleep/Resume-Effekte, oder Anwendungen, die Dateien in schnellen Sequenzen schreiben (temporäre Dateien, atomare Umbenennungen, „Safe Save“). Auf Client-Seite liefert der Sync-Client die wichtigsten Hinweise, weil er Upload/Download-Entscheidungen protokolliert und Sperrsituationen sichtbar macht.

Als robuste Praxis gilt, bei wiederkehrenden Konflikten zunächst die lokale Ursache zu isolieren: ein Gerät als „Autorität“ definieren, die übrigen Clients pausieren, die Anwendung schließen, anschließend den Abgleich abwarten und erst dann erneut parallel arbeiten. So lässt sich unterscheiden, ob die Konflikte aus gleichzeitigem Editieren stammen oder aus einem mechanischen Problem wie lokalen Sperren, zu langen Upload-Warteschlangen oder wiederkehrenden Verbindungsabbrüchen.

Prüfstellen auf Server-Seite: Sperren, WebDAV-Verhalten, Versionen als Rettungsnetz

Auf Server-Seite spielen Sperrmechanismen und die Historie der Datei eine zentrale Rolle. Nextcloud nutzt serverseitige Locking-Mechanismen, um konkurrierende Schreibzugriffe abzufangen; in Störfällen können jedoch verwaiste Locks auftreten, etwa nach abgebrochenen Transfers oder Timeouts. Zusätzlich ermöglicht die Versionierung, ältere Stände einer Datei wiederherzustellen, was bei falsch „zusammengeführten“ Konfliktständen die risikoärmste Rückfallebene darstellt.

• Aktive Sperren erkennen: In der Weboberfläche auf Hinweise wie „Datei ist gesperrt“ achten; bei wiederholten Sperrmeldungen Upload/Download stoppen und zuerst die Ursache (abgebrochene Sitzung, laufender Client, instabile Verbindung) klären.
• Lock-Stau vermeiden: Bei vielen gleichzeitigen Schreibvorgängen (z. B. Massenimporte) eher in Blöcken arbeiten und Clients nicht parallel dieselben Ordner „warmhalten“, um konkurrierende WebDAV-Operationen zu reduzieren.
• Versionshistorie prüfen: Vor jeder „harten“ Entscheidung (Überschreiben/Löschen) die Versionen in der Weboberfläche öffnen und die relevanten Zeitpunkte notieren; die Wiederherstellung über Versionen ist oft schneller als eine forensische Rekonstruktion aus Konfliktkopien.
• Papierkorb als zweite Rückfallebene: Falls bei der Bereinigung Dateien entfernt wurden, zunächst im Papierkorb wiederherstellen, bevor mit erneuter Synchronisation weitere Löschungen propagiert werden.

Bei hartnäckigen Sperrzuständen ist Zurückhaltung sinnvoll: Das manuelle Eingreifen in Sperr-Backends oder Datenbanken sollte nur durch Administrationsprozesse erfolgen, weil unsachgemäße Löschungen die Konsistenz gefährden können. Aus Anwendersicht ist der sichere Weg, alle schreibenden Clients zu beenden, den Serverzustand abzuwarten und danach mit einem einzelnen, stabil angebundenen Client wieder zu starten.

Vorbeugung bei Mehrgeräte-Nutzung: Arbeitsregeln, Dateitypen, organisatorische Leitplanken

Konflikte sind selten reine „Softwarefehler“, sondern meist ein Nebenprodukt paralleler Bearbeitung ohne abgestimmte Abläufe. Prävention beginnt mit der Einordnung: Textformate lassen sich eher zusammenführen, proprietäre Binärformate praktisch nie. Je weniger eine Datei technisch mergebar ist, desto stärker muss der Prozess verhindern, dass zwei Geräte gleichzeitig produktiv daran schreiben.

• Serialisierung kritischer Dateien: Für nicht-mergefähige Formate (z. B. .docx, .xlsx, .pptx, .sqlite, Tresor-Dateien) eine feste Regel: Bearbeitung nur auf einem Gerät zur Zeit, andere Clients pausieren oder Datei vorübergehend aus dem Sync herausnehmen.
• Konfliktanfällige Ordner trennen: Arbeitsordner mit häufigen Speichervorgängen (z. B. Notizen, Projektdateien) nicht mit Archivordnern mischen; so bleiben Konflikte lokal begrenzt und Versionen leichter überschaubar.
• Synchronisationsdisziplin bei Offline-Phasen: Nach längeren Offline-Zeiten zuerst vollständig synchronisieren lassen, bevor eine Datei geöffnet und gespeichert wird; besonders nach Flugmodus, VPN-Wechsel oder Geräte-Ruhezustand.
• Versionierung als Standardabsicherung: Für Bereiche mit hoher Änderungsfrequenz Versionen regelmäßig prüfen und bei wichtigen Meilensteinen zusätzlich eine manuelle Kopie mit Datum im Namen ablegen (z. B. Report_2025-12-14.docx), um Abhängigkeiten von automatischer Aufbewahrung zu reduzieren.
• Kein gleichzeitiges Bearbeiten über verschiedene Wege: Nicht parallel über Weboberfläche (WebDAV), Desktop-Client und mobile App am selben Dokument arbeiten, wenn die Anwendung keine echte Kollaboration unterstützt; Mischbetrieb erhöht die Wahrscheinlichkeit konkurrierender Saves.

Wenn Mehrgeräte-Nutzung unvermeidbar ist, reduziert eine klare Rollenverteilung den Druck auf das Sync-System: Ein Gerät übernimmt die aktive Bearbeitung, andere dienen primär dem Konsum oder dem asynchronen Ergänzen. In Kombination mit konsequenter Nutzung der Versionshistorie und dem geordneten Wiederanlaufen nach Störungen lassen sich Konflikte nicht nur auflösen, sondern langfristig selten halten.