Problem, großes Problem: ownCloud Sync-Client produziert tausende an _conflict-Dateien

Wer Sachen aus diesem Beitrag ausprobiert -> unbedingt eine Datensicherung vorher machen!!!

ownCloud-Anwender, probiert doch mal das bitte auf Eurem Rechner aus, auf dem die persönliche Datenwolke installiert ist:

find /var/www/owncloud/data -type f \( -name *_conflict-* \) | wc -l oder wahlweise find /var/www/owncloud/ -name '*conflict*' | wc -l

Was macht das? Es sucht im Ordner /var/www/owncloud/data nach Dateien, die ein _conflict- im Namen haben. So eine Datei wird dann angelegt, wenn die Synchronisation nicht sicher ist, welche Datei behalten werden soll oder neuer ist. Dann wird nicht einfach überbügelt, sondern sicherheitshalber eine Kopie angelegt.

Nun habe ich meine alte Installation durchgesehen (4.5), wo auch meine Freundin Dateien ihres Macs sichert. Sie beklagte dann und wann Abstürze des Synchronisations-Clients, hat aber auch sehr viele Dateien. auf der 4.5 geht es erst richtig ab: über 110.000 _conflict-Dateien, die sich blöderweise auch wieder auf ihren Mac zurück synchronisiert haben – aber nicht alle, sondern nur ungefähr 50.000 davon. Das ist kein Witz, ich habe nur gestern in der Aufregung vergessen, Screenshots zu machen – war außerdem schon 23 Uhr, da schaltet das Hirn nicht mehr so schnell.

Meine Theorie, die sich auch durch diverse Foren-Einträge zu bestätigen scheint: Das Phänomen tritt auf, wenn ein alter Synchronisations-Versuch einfach abgebrochen wurde. Wie bei mir gestern, als ich nicht warten wollte, bis der Client alles synchronisiert hatte und hab meinen Rechner heruntergefahren. Seit heute morgen synchronisiert der weiter, produziert aber nur noch _conflict-Dateien. Bisher ist mir das nicht passiert, weil sich meine erste Installation so nach und nach gefüllt hat und ich keinen Riesen-Ordner gleich zu Anfangs angegeben habe. Ich verwende übrigens den Client: 1.2.1.

Das Problem hängt also nicht mit ownCloud 5 zusammen, sondern tritt schon länger auf. In dieser Form ist ownCloud mit dem Sync-Client absolut unbrauchbar – es tut mir Leid das so sagen zu müssen, aber das ist nicht reif für die große Bühne. Das frisst Unmengen an unnötigen Speicherplatz und ist schwer zu warten, weil sich diese _conflict-Dateien zum Teil auch auf den Client zurück schleichen.

Noch ein Ding

Bei vielen und großen Datenmengen tut die Erstsynchronisation auf die ownCloud echt weh. Bei, sagen wir 50 GByte Daten, geht das einfach nicht an einem Tag – oder 2 oder 3 … wer seinen Rechner nicht so lange laufen lassen möchte, fällt dann meiner Meinung nach genau in das oben beschriebene Szenario.

Nicht machen!!! In einem Foren-Eintrag (ich verweise absichtlich nicht drauf) wird beschrieben, das man die Tabelle oc_fscache in der Datenbank leeren könne und danach soll man die ownCloud aufrufen, weil das einen Datenabgleich triggert. Das gab nen witzigen Effekt. Es wurden zwar Daten wieder erkannt, aber ich habe nicht alle im Browser gesehen. Wirft man nun den Sync-Client an, werden die Daten nicht von Rechner auf die ownCloud geschoben, sondern ich erhielt lustige Medlungen auf dem Client, dass so und so viele Daten entfernt wurden. Ohne Backup -> DATENVERLUST!

Selbst wenn das funktionieren würde, fällt es spätestens dann auf die Nase, wenn die bald wieder eingeführte Verschlüsselung verwendet wird. Also: Erstens funktioniert es sowieso nicht und zweitens sind die Aussichten nicht sehr rosig.

Was sind die Alternativen?

Tja, das kommt nun darauf an, was man möchte. Aber von diesem Sync-Client habe ich nun erst mal die Nase voll. Ich werde weiter damit testen, aber für einen produktiven Einsatz ist mir der Beobachtungs-Aufwand, ob der Mist treibt, zu hoch.

Eine Möglichkeit ist natürlich, die ownCloud direkt via WebDAV einzubinden und dann rsync oder unison verwenden. In meinem Fall Zum Beispiel so:

• sudo mount.davfs -o uid=bitblokes,gid=users,dir_mode=775 http://192.168.100.138/owncloud/remote.php/webdav/ /home/bitblokes/davtest/
• rsync -avuz /home/bitblokes/ownCloud/ /home/bitblokes/davtest/clientsync/ --delete-after

Die oben beschriebene Synchronisation ist natürlich nur einseitig (unison könnte beidseitg) und beschränkt sich auf einen Rechner. Setzt man Linux, UNIX oder Mac OS X ein und hat die ownCloud wie ich auf einem Linux-Rechner, ist diese Art des Backups außerdem Quatsch – außer man möchte die Daten unbedingt in der ownCloud haben – außerdem sehe ich, dass rsync über den eingebundenen WebDAV-Ordner schneller ist. Binnen einer Stunde hat mir diese Methode zirka 750 MByte kopiert und 480 Dateien und der Sync-Client rödelte gestern 2 Stunden und schaffte weniger als die Hälfte.

Allerdings ist rsync via ssh noch mal so viel schneller als WebDAV – über einen Samba- oder NFS-Share sollte es auch viel zackiger funktionieren. Das ist aber keine Lösung für den normalen Windows-Anwender, weil der kein rsync per Standard hat. In einem Forum habe ich gelesen, dass GoodSync (gibt es auch für Mac OS X und für Linux – aber nur Kommandozeile) wesentlich besser funktionieren soll.

Um ein WebDAV-Verzeichnis einbinden zu können, musst Du allerdings erst das Paket davfs2 installieren. Unter Linux Mint / Ubuntu: apt-get install davfs2

Natürlich kann man sich auch mit diversen Dateimanagern zu WebDAV verbinden. Dann musst Du halt erst herausfinden, wo sich das Ganze eingebunden hat. Das funktioniert am Einfachsten mit mount. In meinem Fall sieht man, dass sich WebDAV von Nemo direkt angesprochen in /run/user/bitblokes/gvfs/… versteckt.

Die Methode ein Backup beim Einstecken einer USB-Festplatte automatisch anzustoßen, ist eher altmodisch, funktioniert aber auch ganz gut.

Die Moral von der Geschicht?

<Polemik>Es scheint, als können Entwickler noch so oft versuchen, das Rad neu zu erfinden – es geht einfach nichts über rsync …</Polemik>. CalDAV, CardDAV und die Web-Oberfläche funktionieren bisher ohne weiteren Probleme. Aber von dem Sync-Client lasse ich erst mal die Finger. Erstens eignet sich die Geschwindigkeit einfach nicht für große Datenmengen und viele Dateien und die daraus resultierenden Probleme sind den Aufwand derzeit einfach nicht wert.

Da war ich gestern noch so glücklich, dass ownCloud mit MySQL anstelle von SQLite so viel schneller ist und nun das … aber für den Einsatz ohne Client bleibt diese Erkenntnis trotzdem ein Gewinn.

Man möge mich bitte nicht falsch verstehen, weil ich das Produkt an sich echt gerne mag und mit ownCloud 5 das Design auch noch wesentlich verbessert wurde. Aber den Sync-CLient habe ich erst mal gefressen. Wenn ich so ein Ding anbiete, dann muss der auch funktionieren. Ich bin nicht der Einzige, der damit Probleme hat und die _conflict-Dateien sind, liest man sich die Foren durch, schon ein Problem mit früheren ownCloud-Versionen. Das kann man unmöglich als stabil betrachten (also das Zusammenspiel mit dem Sync-Client).

Für den Mac meiner Freundin werden wir nun auch die SSH-Methode mit rsync und einem Cronjob verwenden. Sie braucht eigentlich auch nur ein Backup, mag aber Time Machine nicht. Da muss man keine Zusatzsoftware installieren, weil die Komponenten ebenfalls zur Grundausstattung eines Macs gehören. Das Backup läuft dann auch unauffällig im Hintergrund.

So, nun brauch ich meinen zweiten Kaffee … 🙂

---

---