Verzeichnisname zu lang - Synchronisationsfehler

Waldler · April 26, 2020, 10:59am

<Nachdem die Diskussion hier auf Deutsch läuft, wähle ich mal diese Sprache>.

Ich bin auch betroffen von den MagentaCLOUD-Problem mit langen Pfadnamen. Auf einem meiner Windows-Rechner habe ich das Cryptomator-Update auf Version 1.5.1 gemacht und wie verlangt den Tresor auf das neue Format aktualisiert (diese Aktualisierung geschieht zunächst nur lokal, nehme ich mal an). Auf diesem Rechner trat dann unmittelbar der Synchronisationsfehler mit der MagentaCLOUD-Sync-App auf (“die Dateien sind nicht synchronisiert weil zu langer Verzeichnisname”). Also:

Lokaler Tresor neues Format

Cloud-Tresor altes Format

Es wird nicht ge-synct und es gibt dadurch kein “Mischmasch”?!

Auf einem anderen Windows_Rechner mit Cryptomator 1.4. funktioniert alles wie gehabt. Das liegt offensichtlich daran, dass Änderungen auf dem Rechner mit der neuen Version nicht synchronisiert werden.

Meine Fragen:

Wenn ich den Tresor (8 GB) auf das neue Cryptomator 1.5-Format aktualisiere, wie viele Dateien müssen (müßten) dann in die Magenta-Cloud synchronisiert werden? Das ganze 8 GB-Volumen?
Was passiert mit meinen anderen Windows-Installationen mit älteren Cryptomator-Versionen? Müssen alle aktualisiert werden auf 1.5.x? Oder sind die Zugriffe rückwärts-kompatibel?

Danke für die Hilfe im Voraus.

Michael · April 26, 2020, 11:35am

Ich denke das wird aber auch von dem verwendeten Sync Client abhängen. Wenn der nicht erkennt dass es die gleiche Datei mit geändertem Namen ist, dann wird es wohl beim Löschen und erneut hochladen der Datei bleiben.

Müssen alle aktualisiert werden. Tresore mit Format 7 können nicht mit Cryptomator 1.4x geöffnet werden.

infeo · April 30, 2020, 8:10am

Wir haben gestern Abend Version 1.5.2 veröffentlicht, dass eine Migration auch bei kürzeren Pfaden erlaubt. Falls durch die Migrierung eine Datei zu lang werden würde, zeigt Cryptomator nun eine sinnvolle Fehlermeldung an und belässt den Tresor im Format 6 (kompatibel zu Version 1.4.x). Der Nutzer muss dann manuell migrieren und evtl. Dateinamen kürzen.

Gartenstadt · May 4, 2020, 11:33am

Hallo,

leider tritt bei mir das identische Problem bei der Version 1.53 auf.

Sobald ich eine neue Datei in das entsperrte Laufwerk (Tresor) einfüge, erhalte ich von HiDrive die angehängte Fehlermelung. Leider lassen sich keinerlei neue, in den entsperrten Tresor eingefügte, Dateien mit dem Cloudanbieter synchronisieren, da die verschlüsselten Dateinamen durchgehend länger sind, als vor dem Update.

Bei Dateien, die bereits vor dem Update in meinem Tresor waren, tritt dieser Fehler nicht auf. Über einen Tipp würde ich mich freuen. Vielen Danke.
ProblemCry

infeo · May 4, 2020, 12:52pm

Cryptomator verlässt sich darauf, dass bereits beim Erstellen, Verschieben oder Auflisten von Dateien und Ordnern eine Fehlermeldung angezeigt wird. Ohne dies kann Cryptomator nicht erkennen, wie lang die Dateinamen sein können und nimmt die aktuelle Standardlänge von 220 Zeichen.

@Gartenstadt Bei dir scheint das Problem zu sein, dass sich nur der Synchronisationsclient von HiDrive beschwert. Cryptomator braucht aber Fehler auf Dateisystemebene.

Es gibt einen Workaround, aber lese ihn komplett durch bevor du Dinge veränderst

Du kannst händisch eine Dateinamenlänge in der Datei settings.json im Cryptomator Einstellungsverzeichnis %appdata%/Cryptomator/ festlegen.
Suche dazu deinen Tresor unter dem Schlüsselwort directories und füge die Zeile "filenameLengthLimit": XXX wobei du XXX durch dein Limit ersetzten willst.

Damit auch wirklich alle Dateien synchronisiert werden, empfehle ich einen neuen Tresor zu erstellen, dann händisch die Länge anzupassen und schließlich die Daten vom alten in den neuen Tresor zu kopieren.

Summa summarum:

Neuen Tresor im Zielverzeichnis erstellen
Dateinamelängenlimit einstellen (siehe unten)
Daten vom alten in den neuen Tresor kopieren.

Beispielhaft sollte ein Tresor-Eintrag in der settings.json-Datei dann so aussehen:

    {
      "id": "eO89FXzCS0Cs",
      "path": "M:\\tresor",
      "mountName": "tresor",
      "winDriveLetter": "T",
      "unlockAfterStartup": false,
      "revealAfterMount": true,
      "usesIndividualMountPath": false,
      "individualMountPath": "M:\\mnt",
      "usesReadOnlyMode": false,
      "mountFlags": "",
      "filenameLengthLimit": 210
    },

Gartenstadt · May 4, 2020, 2:53pm

Hallo infeo,

vielen Dank für deine ausführliche Antwort.

Gerade habe ich den Dateipfad zur Masterkey-Datei verkürzt. Zur Erläuterung:

zuvor: “E:\Cloud\users\Benutzername\Unterverzeichnis\Unterverzeichnis2\Masterkey”
jetzt: “E:\Cloud\users\Benutzername\Unterverzeichnis\Masterkey”

Und tatsächlich, das Problem ist bereits gelöst. Auch vielen Dank für deinen Workaround. Sollte das Problem erneut auftreten, so weiß ich direkt einen Lösungsweg.

DerDan · May 5, 2020, 5:43am

Danke infeo!

Ich habe auch das Problem, dass beim Einfügen von weiteren Dateien in meinen Tresor die Synchronisation in die MagentaCloud auf die Bretter geht (ich migriere gerade einen ganzen Schwung in die Cloud).

Zu meinem Verständnis: Cryptomator gibt keine Meldung aus, weil er nicht vorab erkennen kann, ob der “neue” (verschlüsselte) Dateiname größer wird als diese (ominöse) Grenze, die bei manchen Anbietern vorgegeben ist?

infeo · May 5, 2020, 8:05am

Nein. Lass mich dies etwas näher erläutern.

Was Cryptomator kann

Cryptomator weiß die Länge der erzeugten Dateien. Es kann auch die maximnale Länge feststellen, solange diese an das Dateisystem gekoppelt ist und dieses eine sinnvolle Rückmeldung gibt.

Die Problematik

Cloudprovider können ein Dateipfad- (und/oder ein Dateinamen-) längenlimit festlegen. Dieses Limit verursacht irgendwo einen Fehler, entweder direkt auf Systemebene (was Cryptomator erkennt) oder nur einem Sync-Client (was Cryptomator nicht erkennen kann). Soweit, so gut.

Nun ist das leider nicht das einzige Problem. Cloud-Speicher lässt sich in Windows auch über WebDAV als Netzwerklaufwerk einbinden. Jedoch ist die Windows interne WebDAV Client Implementierung fehlerhaft und kann Pfade, die länger sind als 260 Zeichen nicht anzeigen, gibt jedoch nur bei bestimmten Operationen Fehler aus. So lässt sich eine Datei ohne Probleme hineinkopieren oder bei Kenntnis des Dateinamens mit dem Terminal verschieben. Nur anzeigen lässt sich das Verzeichnis mit der Datei nicht mehr.

Lösungen

Das zweite Problem lässt sich durch benutzten eines externen WebDAV client (z.b. [MountainDuck] (https://mountainduck.io/)) umgehen. Aber auch Cryptomator erkennt nun, ob der Tresor auf einem Windows gemounteten WebDAV-Laufwerk liegt und passt dementsprechend die maximale Länge an.

Für Problem 1a (Fehler auf Systemebene) funktioniert das eben auch. Nur Problem 1b lässt sich nicht lösen, da Cryptomator nicht mit der Synchronisations-Anwendung kommunizieren kann.

toblas · May 7, 2020, 10:41am

Habe seit der Version 1.5.3 ebenfalls auch wieder Probleme mit der Dateilänge…

Mal so ne Frage: Wenn es bloß einzelne (Cryptomator) Dateien sind, bei welchen der Dateiname zu lang ist, kann ich diesen einfach manuell kürzen bzw. verändern? Oder findet dann Cryptomator die Datei dann nicht mehr und stellt ggf. die Dateien im Tresor nicht mehr korrekt dar?

Bsp.:

Eine Datei heißt: nHGjr97A-3Bkj7qNAAx6TQzMf7vCy96xgiMx47nd33L66FG67UG_wl_ivagZL91330aJ_2PK96FSxlq3fw7c910RGel4MS9LlTsMZquZ-r3g4memi6_N-NN1ifEz7LLiS8FMntWTZIOUT9wkvLITe-hMQP_fOiIJgg4xhnSzAbMmpWi6Q

und wird z.B. in folgenden Dateinamen umbenannt: N1ifEz7LLiS8FMntWTZI449

Wird dann die Datei noch gefunden bzw. kann von Cryptomator eingelesen werden?

infeo · May 7, 2020, 10:57am

Nein. Dateien im Speicherort des Tresors sollten tunlichst nicht angefasst werden.

Was du tun kannst, ist den Namen der betreffende Datei innerhalb des Tresors zu kürzen. Die betroffene Datei kannst du zum Beispiel anhand der Zeitstempel finden.

Randnotiz: Mit Version 1.5.0 wird nun auch bei jedem neu erstelltem Tresor extra eine Datei in den Speicherort des Tresors gelegt, die ausdrücklich davor warnt irgendetwas in dem Verzeichnissen zu ändern.

DerDan · May 9, 2020, 12:33pm

Danke für die ausführlicher Erläuterung infeo!

Ich versuche gerade, meine Dateien verschlüsselt in die Cloud zu übertragen - das ist schon ein wenig. Da es immer wieder zu diesem Problem kommt, habe ich das erstmal abgebrochen. Dabei handelt es sich auch um Dateien, die durch andere Programme erzeugt wurden und die ich nicht umbenennen kann/darf.

Was haltet ihr von folgender Idee: Bei der Erstellung eines Tresors kann eine Zahl eingegeben werden (optional), die die maximale Pfadlänge begrenzt. Cryptomator richtet den Tresor danach aus und bringt den Verkürzungsalgorithmus bei den Dateien zur Anwendung, die diese maximale Pfadlänge nach Verschlüsselung überschreiten werden. D.h. die Pfadlänge der verschlüsselten Dateien bleibt immer unterhalb der “zulässigen” Grenze. Gleichzeitig werden nicht mehr Dateien mit dem aufwendigeren Verfahren behandelt als nötig.

overheadhunter · May 10, 2020, 3:02am

Haben wir auch schon überlegt. Ist nicht unmöglich, aber sollte gut durchdacht sein. Das Problem ist hier die Abwärtskompatibilität. Es müsste ein neues Tresorformat definiert werden, um zu verhindern, dass alte Cryptomator-Versionen derartige Tresore zu öffnen versuchen und dann nicht den konfigurierten Schwellwert, sondern einen eigenen annehmen. Letzteres würde zu Dateninkonsistenzen führen, was unbedingt zu vermeiden ist.

TomA · May 10, 2020, 3:34pm

Stellt sich die Frage: Wie bestimmt man die geeignete Limit-Länge? Ich habe das Limit unverändert auf 220 gelassen. Probleme gibt es beispielsweise bei einer Datei, deren Pfadlänge im gemappten Verzeichnis 160 Zeichen beträgt. Die verschlüsselte Datei hingegen hat eine Pfadlänge von 265 Zeichen, worüber sich Hidrive beim Synchronisieren beschwert.

overheadhunter · May 12, 2020, 6:13am

Wenn das Dateisystem, auf welchem der Tresor gespeichert ist, kein Limit hat und erst zu einem späteren Zeitpunkt die Synchronisation erfolgt, ist es in der Tat nicht möglich, ein solches Limit zu erkennen.

DerDan · May 12, 2020, 6:26am

Ich habe noch ein wenig weiter mit meinen Dateien probiert. Es gibt viele Einflüsse auf den verschlüsselten Dateinamen. Ein wesentlicher scheint die Art der Zeichen zu sein - vor allem Sonderzeichen. Letztendlich bleibt es für den Anwender schwierig zu erkennen, wann eine Datei das Limit reißen wird.

Ich halte es für den besten Weg, auf das “Ziellimit” zu gehen, also die max. Pfadlänge des verschlüsselten Pfades. Der User muss sich nur während der Anlage des Tresors festlegen, ab dann funktioniert der Algorithmus im Hintergrund. Gleichzeitig minimiert man die Anzahl der Dateien, die mit der Verkürzungslogik behandelt werden - nämlich nur die, die Grenze reißen würden. Und ja, dieses Tresor-Format ist nicht abwärtskompatibel - dessen muss man sich bewusst sein.

overheadhunter · May 12, 2020, 6:38am

Genau, das liegt daran, dass Zeichen mehrere Bytes einnehmen können. Insbesondere bei Emojis können (laut diesem Vortrag) da mal für ein einzelnes Zeichen gut 30 Bytes zusammenkommen.

Der Ciphertext für einen Cleartext mit n Bytes ist (16+n)*4/3+4 Zeichen lang.

TomA · May 12, 2020, 8:47am

Na ja, ich weiß, dass die Maximallänge auf meinem Dateisystem 260 Zeichen ist. Nun produziert cryptomator einen Pfad mit 266 Zeichen, obwohl das Standard-filenameLengthLimit 220 ist. Von den 266 Zeichen ist der von cryptomator generierte Teil 236 Zeichen (also auch > 220). Auf was genau bezieht sich denn das Limit?

Und wieso produziert cryptomator in der neuen Version so lange Pfadnamen? Mit 1.4 hat es prima funktioniert.

infeo · May 12, 2020, 6:11pm

Ich habe es schon in einem anderen Thread geschrieben, aber auch hier nochmal:

Man muss zwischen der Pfadlänge und der Dateinamenlänge (evtl. auch Pfadkomponentenlänge) unterscheiden. Wer Lust hat kann für Windows etwas in der Microsoft Doku lesen.

Das Limit bezieht sich auf Dateinamen. Würde es sich auf Pfade beziehen, dann würde es auch “PathLengthLimit” heißen

Wenn dein Dateisystem nur 260 unterstützt, sollte es bei längeren Pfaden auch eine Fehlermeldung ausgeben, was auch Cryptomator erkennen würde. Aber anscheinend unterstützt eine andere Sache in deinem Aufbau keine 260 Zeichen.

Alles weitere kann man hier lesen: Error during updating vault (Cryptomator 1.5.3)

JCrypt · May 17, 2020, 5:06pm

Interessant, ich bin in Kombination mit HiDrive von dem gleichen Problem betroffen. Ich habe jetzt mal in die settings.json geschaut und bei allen Tresoren ist das filenameLengthLimit auf 220 gesetzt. Außer bei dem, bei dem das Problem auftritt.

"filenameLengthLimit": -1,

Dabei habe ich dort nie manuell etwas geändert. Wie kommt das?

DerDan · May 24, 2020, 4:16pm

Ich vermute mal, dass dieser Tresor noch mit einer Version erstellt ist, die diesen Paramter noch nicht kannte. Wenn Du den Tresor dann migrierst, müsste dort 220 eingetragen werden. Wie geschrieben: Vermutung.