sind Probleme beim Zusammenspiel von Cryptomator und Tools wie robocopy, FreeFileSync oder Syncback bekannt?
Ich verwende Cryptomator in Version 1.4.0-rc1 unter Windows 10 x64 mit Dokany
Hier wird von einem ähnlichen Verhalten berichtet, allerdings in Verbindung mit WebDAV
Folgendes Problem: Ich synchronisiere ca. 60.000 Dateien von einem lokalen Order (D:\Daten) in ein Cryptomator-Laufkerk (S:) - das auf D:\Cloud\Cryptomator verweist - um ein verschlüsseltes Backup in der Cloud zu haben. Bei robocopy mit dem Befehl /mir
Für meine Tests habe ich die Sync-Software meines Cloudanbieters deaktiviert.
Sowohl bei robocopy als auch bei FreeFileSync und SyncBack habe ich das Problem, dass bei jedem Sync Daten von Quelle auf Ziel kopiert werden, die angeblich neu sind oder geändert wurden. Das ist definitiv nicht der Fall. Die Dateien wurden zwischen den Sync-Vorgängen nicht angelegt, geöffnet, geändert etc.
Die Anzahl der betroffenen Dateien schwankt zwischen 15 und 50.
Ich konnte bisher kein Muster erkennen, warum die Daten als neu/geändert erkannt werden.
Wenn ich den Quell-Ordner mit einem unverschlüsseltem Ziel-Ordner auf einer externen Festplatte (NTFS) synchronisiere, tritt dies nicht auf. Daher vermute ich, dass das Problem bei Cryptomator liegt??
Habt ihr einen Tipp für mich bzw. welche Informationen kann ich liefern um dem Problem auf die Spur zu kommen?
Hallo Michael,
das wäre ja ein downgrade. Bin aktuell auf 1.4 RC1
Ich glaube ich weiß was Du meinst. Die Initiale Verschlüsselung meiner Dateien habe ich mit Version 1.3.4 und WebDAV gemacht. Dort gab es wohl das Problem mit den Timestamps.
Wenn ich jetzt einmal komplett neu meine Dateien mit der Version 1.4 und Dokany verschlüssle, sollte das Problem bei der Verwendung von robocopy & Co. nicht mehr auftreten???
Da es noch kein Release von 1.4 gibt soweit ich weiß, bist du also wohl auf der Beta1
Das timestamp problem gab es auch noch in der Beta 1 und Beta2 und es ist irrelevant mit welcher Version du ursprünglich die Dateien verschlüsselt hast.
Kein Thema
Nur was machen wir jetzt mit dem Problem bei der Verwendung von Tools wie robocopy etc.?
Du sagst das es irrelevant ist, mit welcher Version ich die Daten verschlüsselt habe.
Ich hätte gedacht, dass ein Neuverschlüsseln mit der neuesten Version hilft?
Mmm… Testen ist mit 60.000 Dateien / 500 GB etwas schwierig - zumal das Problem nicht bei allen Dateien auftritt, sondern immer nur bei 15 - 50.
Bei jedem Sync-Vorgang findet robocopy weitere Dateien die angeblich neu sind oder geändert wurden - was sie definitiv nicht sind.
Ich denke nicht dass die Verschlüsselung das Problem ist. Die Sync Programme nutzen entweder den timestamp oder das archivbit. Aus irgend einem Grund wird also bei den betroffenen Dateien eines davon geändert und das Sync Programm meint es läge eine Änderung vor.
Mit der Verschlüsselung selbst sollte das also nicht zusammen hängen.
Um etwas in diese Diskussion einzugreifen:
Die Sache mit den Zeitstempel sollte sich eig. erledigt haben.
Was allerdings sehr gut möglich ist, dass zuviel Last auf dem Laufwerk erzeugt wird und deshalb einzelne Dateisystemanfragen nicht bearbeitet werden können.
Dokany läuft noch im singlethreaded Modus, d.h. sobald es mehrere Anfragen gibt, kann das system überlasten. Multithreading ist für 1.4.1 geplant.
Um die These zu überprüfen kannst du @Major.Tom bei robocopy die Option /MT:1 hinzufügen, dass robocopy anweist, selbst nur einen einzigen Thread zu verwenden.
Hallo infeo,
auch das hilft nicht. Robocopy findet nach jedem Durchgang weitere Dateien die angeblich neu sind oder geändert wurden. Was sie definitiv nicht sind.
Das Gleiche mit der Software “FreeFileSync”.
Hier treten sogar teilweise folgende Fehler auf: “Fehlercode 183: Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist [MoveFileEx]”
Quelle/Ziel ist weder gesperrt noch geöffnet.
Da ich meine Dateien 2-fach sichere
1 - unverschlüsselt externe Festplatte
2 - Cryptomator verschlüsselt + anschließender Cloud-Upload
und die Probleme nur bei Cryptomator auftreten, gehe ich davon aus das es an Cryptomator liegt.
Daher immer noch die Frage: Kann es Probleme beim verschlüsseln mit Version 1.3.4 (WebDAV) gegeben haben? Wenn ja, würde ich mir die Mühe machen und nochmal meine 60.000 Dateien mit Version 1.4.0 (Dokany) neu zu verschlüsseln.
jetzt wird es ganz kurios: Ich dachte der Fuchs ist schlau und habe den Cryptomator Debug-Modus aktiviert - in der Hoffnung im Log-File einen Fehler zu finden.
Mit aktivierten CM-Debug-Modus läuft Robocopy perfekt durch.
Es werden nur die neuen/geänderten Dateien erkannt.
(Schalte ich den Debug-Modus aus, kommen wieder willkürliche Dateien die angeblich angelegt/geändert wurden - aber nie sind)
In FreeFileSync erhalte ich nach wie vor bei einigen Dateien einen Fehler.
Generell werden aber auch nur die wirklich neuen/geändert Dateien angezeigt + die Dateien mit Fehler.
“Fehlercode 183: Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist [MoveFileEx]”
Hier kann ich entsprechende Einträge im LogFile finden:
19:39:18.783 [Thread-2449] ERROR o.c.frontend.dokany.ReadWriteAdapter - (488) Error filling Win32FindData with file 20081123_019.jpg. Occurred error is {} 19:39:18.783 [Thread-2449] ERROR o.c.frontend.dokany.ReadWriteAdapter - (488) findFilesWithPattern(): Stacktrace: java.lang.Error: Invalid memory access
_ at com.sun.jna.Native.invokeVoid(Native Method)_
_ at com.sun.jna.Function.invoke(Function.java:408)_
_ at com.sun.jna.Function.invoke(Function.java:354)_
_ at com.sun.jna.Function.invoke(Function.java:308)_
_ at com.sun.jna.CallbackReference$NativeFunctionHandler.invoke(CallbackReference.java:679)_
_ at com.sun.proxy.$Proxy9.fillWin32FindData(Unknown Source)_
_ at org.cryptomator.frontend.dokany.ReadWriteAdapter.lambda$findFilesWithPattern$1(ReadWriteAdapter.java:541)_
_ at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)_
_ at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)_
_ at java.base/java.util.Iterator.forEachRemaining(Unknown Source)_
_ at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown Source)_
_ at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)_
_ at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)_
_ at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)_
_ at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)_
_ at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)_
_ at java.base/java.util.stream.ReferencePipeline.forEach(Unknown Source)_
_ at org.cryptomator.frontend.dokany.ReadWriteAdapter.findFilesWithPattern(ReadWriteAdapter.java:537)_
_ at com.dokany.java.DokanyOperationsProxy$FindFilesWithPatternProxy.callback(DokanyOperationsProxy.java:112)_
_ at jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)_
_ at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)_
_ at java.base/java.lang.reflect.Method.invoke(Unknown Source)_
_ at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520)_
_ at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)_ 19:39:18.785 [Thread-2449] ERROR o.c.frontend.dokany.ReadWriteAdapter - (488) Error filling Win32FindData with file 20081123_007.jpg. Occurred error is {} 19:39:18.785 [Thread-2449] ERROR o.c.frontend.dokany.ReadWriteAdapter - (488) findFilesWithPattern(): Stacktrace: java.lang.Error: Invalid memory access
danke für die nähere Untersuchung und die Log Datei! Dass es durch Aktivierung des debug-logs funktioniert ist überaus seltsam… Aber es wurde auch auf github schon gemeldet, dass bei bestimmten Anwendungen die Zeitstempel nicht übernommen wurden.
Das sollte unbedingt im Github-tracker von Cryptomator landen. Falls du einen eigenen Account hast, kannst du ja ein Issue erstellen. Ansonsten werde ich denke ich die infos zusammenklauben und eines eröffnen.
Klasse! Vielen Dank. Gerade wollte ich einen Bug Report schreiben.
Ob es bei Robocopy am Timestamp liegt wie Du schreibst, kann ich nicht sagen. Ich finde ex äußerst merkwürdig, dass bei jedem Durchlauf neue Dateien in Robocopy angezeigt werden, die angeblich neu oder geändert sind und im vorherigen Durchlauf definitiv nicht kopiert wurden.
Was Du noch erwähnen könntest: Die Daten aus dem LogFile stammen durch die Verwendung von FreeFileSync. Das Tool spuckt bei einigen Dateien diesen Fehler aus. “Fehlercode 183: Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist [MoveFileEx]”
