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.
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.
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.
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.
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.
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.
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) - #7 by infeo
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?
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.
Gibt es jetzt hierzu schon eine Lösung mittels Update, oder funktioniert das nur mit dem hier angegeben Workaround von Infeo?
Ich hab das Problem auch seit 1.5 mit der Magenta Cloud
Wenn du mit Problem die Dateinamenlängenlimitierung des Magenta-Sync-Clients meinst, dann kann ein Update das nicht lösen. Schließlich unterstützt dein Dateisystem die volle Nameslänge und Cryptomator erkennt nicht, ob du die Magenta-Cloud benutzt. (und es ist sehr unwahrscheinlich, dass es das jemals wird)
Ich habe bezüglich der Problematik auch einen eigenen Artikel geschrieben, siehe [1.5.0+] File name too long.
1 Like
Ok ich hab das anhand der Anleitung mal gemacht, aber Magenta hat immer wieder neue Dateien die nicht passen. Er zeigt immer nur eine an und wenn ich das gefixed hab, kommt die nächste Datei.
Wollte das nun machen, dass ich einen neuen Tresor anlege, die Länge festlege und dann die Dateien rein synchronisiere - nur nun die Frage: Mit welchem Programm, kann man die Daten synchronisieren? Wollte das mit robocopy machen, aber Robocopy erkennt das Cryptomator Laufwerk nicht 
Versuchs mal ohne Admin-Rechte. Bei mir klappt es ohne Probleme, ich verwende Cryptomator 1.5.5 und Dokany.
Hallo zusammen,
ich habe ebenfalls Probleme mit HiDrive von Strato und Cryptomator. Die Anleitung von infeo habe ich bereits umgesetzt. Sprich ich habe einen neuen Tresor angelegt, bin in die json-Datei und habe für diesen Tresor die maximale Länge reduziert. Wenn ich die Daten in den Tresor kopiere, erhalte ich keine Fehlermeldung bzgl. der Länge. Erst wenn HiDrive mit dem Upload beginnt.
Ich habe mit der maximalen Länge gespielt, aber ich komme nicht weiter. HiDrive gibt einfach immer wieder Fehlermeldungen aus. Ich bin am Verzwifeln und überlege, ob ich auf Veracrypt umsteigen soll, persönlich finde ich für meinen Einsatz Cryptomator aber deutlich besser.
Ich freue mich über jegliche Rückmeldungen! Danke im Voraus!
Viele Grüße
Willbaer
Hallo Willbaer,
ich hatte das Problem die letzten Tage auch erneut.
Du musst auf zwei Dinge achten:
-
Der gesamte Pfad darf für Hidrive nicht länger als 260 Zeichen sein. Zum Teil legt cryptomator selbst innerhalb des Containers eine Ordnerstruktur an, die relativ viele Zeichen beansprucht.
-
Wenn man in Cryptomator nach dem Editieren der json Datei eine Einstellung am Container ändert scheint die manuell angepasste maxfilenamelength wieder mit 220 überschrieben zu werden.
Viele Grüße
Hallo JCrypt,
vielen Dank für deine Rückmeldung. Es lag wohl an der zusätzlichen Ordnerstruktur. Ich bin dennoch etwas irritiert, dass Cryptomator alles nimmt ohne eine Fehlermeldung auszugeben und HiDrive sich dann später beschwert. Ich bin jetzt so vorgegangen, dass ich immer nur einen Teil meiner Daten in den Container kopiert habe. Kam keine Meldung von HiDrive, dann war der nöchste Stoß dran. Das ist etwas umständlicher, aber es funktioniert. Nach vorne hin, werde ich jedoch darauf achten nicht mehr als zwei Orderebenen zu verwenden 
Nochmals vielen Dank und viele Grüße
Willbaer
Mit der JSON Anpassung änderst du nur die maximale Länge von Dateinamen. Nicht des kompletten Pfades. Hidrive meckert aber wegen der Länge der Pfade.
Ich denke hier liegt die Ursache da trotz deiner Dateinamen Limitierung die Pfade dennoch zu lang für hidrive sind.
Zur Ermittlung des korrekten Wertes für die maximale Gesamtlänge des Pfades (Siehe Kommentar von @JCrypt ) hilft diese Erklärung.
Hallo Michael, vielen Dank auch für deine Rückmeldung. Du hast Recht, ich war so auf die Länge fixiert, dass ich nicht bemerkt habe, dass ich nur die File-Länge angepasst habe. VG
Ich benuzTE** die letzte verfügbare Version von Gryptomator vor wenigen Minuten und habe ebenfalls des Problem eines zu langen Pfadnamens resp. Dateinamens beim Hochladen in die Magentacloud.
Ich habe die vorherigen Beiträge überflogen und will meine Meinung dazu mitteilen:
Das Problem tritt anscheinend erstmals bei einem Update des Cryptomators auf eine neuere Version auf.
Vorher war dies nicht der Fall.
Siehe x Beiträge der User.
Wie kommt man dann darauf, das dies ein Fehler der TelekomCloud sein soll?
Die hat doch nichts geändert, oder liege ich da falsch?
Dann das ganze Gerede von:
Was das Programm kann, was es nicht kann, das es Fehler auf Dateiebene erkennen kann, auf einer anderen Ebene nicht … bla, bla, bla.
Was soll das?
Ich habe die gleichen Daten mit Boxcryptor in die Telecomcloud hoch geladen, das ging einwandfrei, keine zu lange Pfade, keine zu lange Dateinamen!
Die gleichen Daten in die gleiche Cloud mit Cryptomator und ich werde überfallen mit Fehlermeldungen Betreff zu langer Pfade, bla, bla, bla.
Wie von anderen Usern hinlänglich beschrieben.
So, einmal mit Boxcryptor, einmal mit Cryptomator, die gleichen Daten in die gleiche Cloud und wenn es mit Cryptomator nicht geht, dann soll die TelekomCloud schuld sein.
Sorry, haltet ihr die User für blöde?
- Das Gefummel mit dem Eintrag in die settings.json!
Was soll das, das ist euer Job, das solltet ihr in euer Murksprogramm reinschreiben und nicht dem User überlassen.
Besonders nervend ist, dass es auch damit nicht klappt.
Ob ich als filenameLengthLimit das Lebensalter meines Opas, oder den Kontostand meines Guthabens eintrage, den Teufel hilft es was …
Die gleichen Fehlermeldungen wie vorher!
Aber ihr habt die User beschäftigt, total sinnlos zwar, man hätte auch Löcher graben und wieder zuschütten gekonnt, aber Hauptsache beschäftigt.
Seit ihr Ergtherapeuten oder Programierer?
Genauso gut kann ich 3 mal links und 3 mal rechts um den PC laufen, kryptische Beschwörungsformeln murmeln und zu Bill Gates beten, nichts hilft es, euer Murksprogramm läuft nicht und damit basta!
Bin ich froh, dass es eine Löschtaste gibt.
Und damit Schluß, ich suche mir ein Programm das tut was es soll.
Viel Spaß noch mit dem Murks
Hallo Community,
hat sich bei diesem Thema mittlerweile etwas bewegt?
Der workaround scheint ja mit Version 1.6xx nicht mehr zu funktionieren.
Oder ist cryptomator damit mit magentacloud und hidrive grundsätzlich inkompatibel?
Danke schonmal!