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

1 März 2013 23 Kommentare Autor: Jürgen (jdo)

ownCloud Logo 150x150Wer 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.

ownCLoud-Sync-Client produziert _conflict-Dateien

ownCLoud-Sync-Client produziert _conflict-Dateien

_conflict-Dateien im Browser zu sehen

_conflict-Dateien im Browser zu sehen

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.

Auch möglich, aber kryptischer

Auch möglich, aber kryptischer

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.

Galerie-Ansicht: ownCloud 5

Galerie-Ansicht: ownCloud 5

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 … 🙂

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
oder bitcoin - Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK). Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!
 Alle Kommentare als Feed abonnieren

23 Kommentare zu “Problem, großes Problem: ownCloud Sync-Client produziert tausende an _conflict-Dateien”

  1. Christoph sagt:

    Hey,

    ich sehe das genau so wie du. Das mit den Conflikt Dateien habe ich gerade erst gesehen. Bevor ich deinen Artikel gefunden habe. Der hat locker mal beim Syncen aus 60k Dateien 81k Dateien gemacht!! oO
    Ich habe aber auch noch ein ganz anderes Problem, nach welchem ich eigentlich gegooglet habe: Sobald man alles ordentlich gesycnt hat(hatte ich schonmal hinbekommen, 2MB Upstream 1 Tag warten ;), und man diese 60k Dateien in seinem Ordner und auf der Cloud hat, fängt der Spaß an. Alle ca. 10 Minuten rattert mein Mac mit 100% Prozessorlast und das für ca. 30 Minuten. Nach 10 Minuten geht das Spiel von vorne los. Das ist bestenfalls eine Alpha Version aber niemals eine 1.2.1.
    Wirklich schade weil alles andere is super! Webinterface Cal und CardDav.

    Vielleicht gibt es in Zukunft ja Besserung. Ich bleib erstmal bei Dropbox in Verbindung mit Boxcryptor, da ich sehr sensibele Daten auf mehreren Geräten brauche.

    Danke für deinen Artikel. Feed abboniert. 🙂

    • jdo sagt:

      Ich bin nicht glücklich über den Umstand, aber froh, dass ich nicht der einzige mit dem Problem bin 🙂

      • Christoph sagt:

        Ich teste gerade Teamdrive in Verbindung mit dem Webdav Speicher. Bisher läuft das alles super!
        Leider wird das Webpanel unsinning da alle Dateien verschlüsselt sind. Kann man jetzt positiv oder negativ sehen. Gibt aber eine USB Stick Variante des TEamdrive Clients.

        Kannst du ja mal testen. 🙂

        • jdo sagt:

          Das sieht in der Tat interessant aus ... schreibe ich mir auf die ToDo-Liste. Danke für den Tipp!

        • jdo sagt:

          Hab ich gerade mal angesehen. Gefällt mir aber nicht besonders. Einmal missfällt mir die erwzungene Registrierung, die man unter dem Deckmantel Sicherheit verschleiert. Dann ist die Synchronisierung eigentlich für die Katz, da ich auf meine Daten via Browser nicht zugreifen kann. Ich brauche immer den Client dazu. Mir persönlich taugt das nicht - da kann ich mir die ganze ownCloud sparen und gleich HiDrive oder so einen Dienst in Anspruch nehmen.

  2. Joh sagt:

    die ganze webdav/davfs2 rsync geschichte hat einen haken, naemlich die modifytime. davfs2 cached lokal, laedt hoch, und der webdav server setzt die time, lt. davfs2 entwickler haben sie keinen einfluss darauf wie die server dies handhaben, d.h. die dateien auf dem server sind immer etwas neuer als die lokalen.
    ich selbst hab schon stress mit davfs2 gehabt, als der upstream etwas unzuverlaessig war, und files einfach nicht auf dem webdav server abgelegt wurden.
    alles krampfig...

    • jdo sagt:

      Warum nimmt man in dem Fall nicht so etwas wie MD5-Summen zu Hilfe. In der jetzigen Form setze ich den Sync-Client auf keinen Fall ein, weil das eine Katastrophe ist. Auf dem Mac meiner Freundin kommt der Client außerdem nicht mit X-Tausend Dateien zurecht, stürzt dann und wann ab und produziert dann diese _conflict-Dateien. Man ich Depp hätte nen Screenshot machen sollen von den 110.000 Dateien, die es mir zusätzlich auf den Server geschossen hat. Aber ich war so perplex in dem Moment ... 🙂

  3. heyho sagt:

    Heyho, wie ich gerade gesehen habe wurde gestern 1.2.3 released unter anderem stand da bei den fixes: [Fixes] detect ‘wrong’ conflict files on client side.

    Eventuell ist das Problem jetzt behoben!? Habe selbst noch nicht owncloud installiert oder getestet deswegen kann ich dazu nichts sagen, wäre aber toll wenn es von euch jemand bestätigen könnte. 🙂

  4. stefan sagt:

    Sei doch froh, dann haste wenigstens was zu lesen

  5. icke sagt:

    Also bei mir sind keine conflicts mehr aufgetreten, seit ich die Versionierung ausgeschalten habe ...

  6. otto sagt:

    kann das nicht nachvollziehen.
    Habe kürzlich ownCloud auf unserem Debian-Server installiert,
    mein Verzeichnis mit > 5 GB eingebunden,
    die Synchronisation mehrfach abgebrochen,
    Ergebnis:
    find /var/www/owncloud/ -name '*conflict*' | wc -l
    1

    • jdo sagt:

      touch verwendet? Wo kommt denn das 1 her? Wie schon mal beschrieben, trat das Problem am brachialsten beim Mac auf ... ob nur eine oder 100.000 Dateien ist egal, es ist ein böser Bug. Solange der nicht gefixt ist, kommt mir der Client nicht mehr in die Tüte. Ich kann den Fehler sehr einfach reproduzieren, womit die Entwickler der Sache auf den Grund gehen könnten. Eine Antwort eines Entwicklers, dass "touch" keine üblich Methode sei, ist nicht akzeptabel. Das wird in der Tat so kein Mensch verwenden, aber man kann daraus schließen, dass der Bug was mit Zeitstempeln zu tun hat.

  7. smoeschter sagt:

    Ich weiß es ist ein wenig out of Topic, aber nach mehreren Fehlversuchen mich im ownCloud Forum zu registrieren (bekomme die Activation Mail einfach nicht und den Boardadmin kann ich nicht kontaktieren weil ich nicht Registriert bin) stell ich die Frage mal hier:
    Habe ownCloud 5 auf einem FreeNAS 8.3.1-P2 release laufen. Funzt soweit auch ganz gut. Die Freigaben vom FreeNAS hab ich über die External App in oC gemmounted und auch das macht keinen stress. ABER aus irgendwelchen Gründen zeigt mir das Mistding von oC an das mein Speicherplatz fast voll ist, was bei 6TB und gerade mal genutzten 342GB wohl kaum der Fall sein kann. Komischerweise wird mir in der Leiste oben unter "Persönlich" angezeigt das ich 341GB von den verfügbaren 342GB benutze. Merkst was? Warm zeigt er mir die Vorhandene Datenmenge an und nicht den verfügbaren Speicher? Falls da jemand eine Lösung hat wär ich fast auf Knien dankbar!Lösungen hab ich trotz Google und CO nicht gefunden.

  8. Tobias sagt:

    Vielen Dank für den interessanten Artikel. Ich nutze ebenfalls ownCloud in Verbindung mit einem Mac Client und habe mit dem Dateisync so ungefähr alle hier beschriebenen Probleme.

    Wenn ich direkt in einem ownCloud-Ordner arbeite und der Client an ist, wurden sehr viele Konfliktdateien erzeug. Außerdem hatte ich ständig eine Prozessorlast von 100%. Für dieses Problem gibt es bereits ein Ticket, die Frage ist nur, wann das gefixt wird. Wenn ich das richtig sehe, hängt das damit zusammen, dass Dateiänderungen regelmäßig überprüft werden, anstatt sich beim Dateisystem für Änderungsevents anzumelden. Dies ist sehr ineffizient.

    Da CardDAV und CalDAV aber einfach perfekt funktionieren, bleibe ich dennoch bei ownCloud, nutze jetzt jedoch das von Dir genannte GoodSync in Verbindung mit WebDAV. Dies funktioniert nach ersten Tests sehr viel besser 🙂

  9. Jürgen sagt:

    Das Problem tritt Ende Dezember 2013 immer noch auf...
    http://idienstler.de/2933/warnung-owncloud-nicht-fuer-produktivsysteme-einsetzen/
    Sehe das auch so das darf gerade bei so einer Software einfach nicht passieren.

  10. […] Analyse weit gefehlt. Die Ursache dafür liegt alleine bei ownCloud. Im Forum bei ownCloud und in diversen Blogs findet man diesbezüglich auch bereits einige Fehlermeldungen vor die allesamt auch den gleichen […]

  11. Tom sagt:

    im aktuellen OC 1.8.1 (mit OC Server 7.0.4.2) Client für Windows: Wenn man einige hundert Dateien hat bricht der Windows Client einfach mal so ab. Kein ersichtlicher Grund nur Meldungen wie SyncError oder "Operation aborted" oder "unable to open device". Das tritt aber nicht auf, wenn man nur wenige Dateien/Ordner hat. Vorallem beim ersten Sync klappt das nicht d.h. der Fehler tritt zum Teil sogar nach dem Start auf egal ob man das Zeuch neu installiert usw. und der Server nagel neu ist.

    Der Client ist ab hunderten Dateien nicht brauchbar mal synccht er ne Weile und beim anderen male bricht er ab. Aber abbrechen das passiert im Grunde immer ganz besonders wenn man wie wir über 2000 Dateien und viele Ordner auf dem Server hat. OwnCloud selbst ist klasse aber der Windows Client zu dem es keine Alternative in dieser Form gibt ist einfach Mist. Sehr schade denn die Kudnen müssen sich nun mit dem Browser begnügen, bis der Hersteller einen besseren Client veröffentlicht.

  12. Tom sagt:

    Mal einen Report: Ich habe nun auf OC 8.0.3 aktualisiert und nach wie vor klappts mit den neuesten SyncClioents nicht. OC kann ich daher so nicht empfehlen es hat massive Probleme mit WebDAV das läuft gar nicht "rund". Ich suche derweil eine Alternative OC kann man so keinem Kunden anbieten. Schade aber die 2 Wochen sind fürn A die man da investiert hat vorallem: Eine Lösung gibt es nicht.

  13. Tom sagt:

    Danke 🙂 habe nun auf ownclud 8 aktualisiert tausend Einstellungen getestet Resultat: ownCloud Client shit läuft nicht ständig WebDav Fehler der feinsten Sorte (filesize, timeout etc). Nun habe ich von einem User den Tipp für WebDrive bekommen das ist etwas langsamer dafür läuft es aber. Seit dem keinerlei Probleme mehr. Es ist offensichtlich so, das der ownCloud Client auch der 1.8.1 massive Probleme mit WebDav hat. Der ownCloud Server an sich ist nicht das Problem sondern der Client.

    Der ownCloud Client versucht ständig zu resyncen es kam hier immer wieder zu Fehlern und es spielt keine Rolle, was man einstellt das Problem existiert immer und tritt zufällig auf. Der Client ist nicht fehlertolerant, er kann nicht mit WebDav stabil umgehen und nutzt kein Caching wie WebDrive alles im allen ist der ownCloud Client so unbrauchbar. Mit WebDrive hingegen klappt es das lass ich mir das Geld kosten. Ihr könnt es gern mal testen Ihr werdet sehen, das das sehr gut funktioniert.

Antworten