Ich wollte vor ca. zwei Jahren mal Cryptomator nutzen, aber es gab immer Synchronisationsprobleme, weil bei der Dateinamenverschlüssung (einfach andere Dateinamen) zu lange Namen vergeben wurden. Hat sich das erledigt?
Die Standardeinstellung für die mögliche Dateinamenlänge war einfach viel zu hoch angesetzt, sodass der Pfad + Dateiname häufig zu lang für einige Clouds waren. 260 Zeichen oder so.
Man konnte zwar manuell diese viel zu hohe Dateinamenlänge beschränken, was zwar geklappt hatte, aber mir damals doch zu blöd war. Da erwarte ich als Standard eine vernünftige Umsetzung. Vor allem, was sollte ein über 200 Zeichen langer Dateiname bringen?
Tut mir leid für einen Extra-Thread, aber meine Zeit ist mir zu kostbar, um noch mehr zu vergeuden wegen dieses absolut unnötigen Problems.
"Um die Kompatibilität zu maximieren, müssen wir sicherstellen, dass die Chiffretextnamen eine Länge von 255 Zeichen nicht überschreiten. Da einige Cloud-Sync-Dienste einer Datei im Falle von Konflikten möglicherweise ein Suffix hinzufügen möchten, haben wir uns entschieden, höchstens 220 Zeichen zu verwenden.
Wenn ein verschlüsselter Name (einschließlich seiner .c9r Erweiterung) diese 220 Zeichen überschreitet, erstellen wir stattdessen ein Verzeichnis, das nach seinem viel kürzeren SHA-1-Hash und der .c9s Erweiterung benannt ist. Zusätzlich erstellen wir eine Reverse-Mapping-Datei mit dem Namen, die name.c9s die Originaldatei in diesem Verzeichnis enthält."
Also noch das gleiche Trauerspiel, oder was soll der Text bedeuten? Ich musste damals die Höchstlänge manuell auf 160 oder 180 verkürzen, um keine Synchronisationsprobleme mehr zu bekommen.
Ich werde diesen Thread in zwei Jahren noch mal wiedererwecken. Vielleicht hat es sich dann gebessert.
Cloud-Dienste die nur derartig kurze Dateinamen unterstützen sind heutzutage eher selten. Eine Cloud unabhängige Software kann nicht auf sämtliche Besonderheiten eines einzelnen Cloud-Dienstes Rücksicht nehmen, zumal wenn bestimmte Vorgaben nicht dem Stand der Technik entsprechen. Sofern es nicht möglich ist einen geeigneten Cloud-Dienst zu verwenden kann das “Trauerspiel” dauerhaft gelöst werden indem statt Cryptomator eine andere Lösung verwendet wird.
Ich werde gar nicht erst testen, ob meine beiden derzeitigen Clouds mit Cryptomator funktionieren. Ist mir die Mühe nicht wert.
Nenne mir einen Grund für den Sinn eines 220 Zeichen langen Dateinamens. Vor allem, wenn es mit 160 Zeichen keinerlei Probleme mehr gibt - wenn man es mit den Pfaden nicht grad übertreibt natürlich.
Der Sinn besteht darin das alle heute üblichen Dateisysteme mindestens Dateinamenlängen von 255 Zeichen unterstützen. Mit 220 Zeichen bleibt man deutlich unter der Länge von 255 Zeichen, so dass es überwiegend keine Probleme mit der Dateinamenlänge gibt.
Es ist doch nachvollziehbar dass ein Software sich an etablierten Standards orientiert und nicht jeden Einzelfall berücksichtigen kann. Wenn Deine Cloud-Lösung von heute üblichen Standards abweicht (oder es Zeitverschwendung ist dies herauszufinden) ist Cryptomator in Deinem Fall keine geeignete Lösung.
Es ist nicht nur der Dateiname! Der Pfad kommt noch hinzu! Frag mich jetzt nicht ob beide oder einer von beiden: der Pfad des Cloudverzeichnisses / der Pfad innerhalb der Cloud.
War vor zwei Jahren. Und vor allem waren es dann nur einzelne zufällige Dateien, wo diese Länge überschritten wurde.
Und noch mal: Was ist der Sinn eines so langen Dateinamens?! Weil man es machen kann, ist kein Sinn!
Nein, der Pfad kommt garantiert nicht hinzu. Da sich das verschlüsselte Dateisystem einer flachen Hierarchie bedient sind lange Pfade dann sogar viel kürzer.
Bezüglich der Dateinamenlänge habe ich ja schon geschrieben das man sich an gängigen Dateisystemen orientiert die eine Dateinamenlänge von 255 Zeichen (oder mehr) unterstützen.
Natürlich kann man alles Programmieren, man könnte ja auch die Forderung aufstellen dass die Dateinamen MS-DOS kompatibel sein sollen, das wären maximal 8 Zeichen + 3 Erweiterung, da könntest Du ja auch die Frage aufwerfen “Warum Länger als 8 Zeichen, wenn es doch mit 8 Zeichen geht”. Nein, so verfährt man natürlich nicht, man orientiert sich an gängigen Standards und das sind nun einmal Dateinamenlängen von 255 (bzw. 256) Zeichen.
Tut mir Leid. Ich beende das hier jetzt mal.
Inhaltlich und fachlich kommt nicht viel und irgendwie habe ich den Eindruck als ob mich mit einem Fanboy unterhalte.
PS: Unteren Post würde ich fast unterschreiben, aber ich bin nicht so genervt, weil ich es mir einfach erspare, bis es vielleicht doch mal gescheit programmiert wurde.
Kurzes Statement, aber bei der langen Diskussion hätte man es tatsächlich auch einfach testen können. @Rainer hat das alles eigentlich schon ziemlich richtig gesagt alles, aber ich fasse den Gedankengang bei der Entwicklung gerne noch mal zusammen:
Durch die Dateinamensverschlüsselung „bläht“ sich der Dateiname etwas auf, aber nicht „unnötig“ und weil wir Bock drauf haben, sondern weil durch die Verschlüsselung und das Encoding nunmal etwas mehr „dazukommt“. Diese Entscheidung kann man im Nachgang natürlich hinterfragen, aber für das aktuelle Schema haben wir uns für AES-SIV + Base64url-Encoding + Dateiendung .c9r (4 Zeichen) entschieden. Wenn ich das richtig im Kopf habe, wird der Dateiname um ca. 4/3 größer als der Klartextname. War damals sogar noch „schlimmer“, als wir Base32 benutzt haben, dort war das Verhältnis 8/5, soweit ich weiß. Wir wissen, dass Boxcryptor Base4K entwickelt hat, womit eine weitere Optimierung möglich wäre, aber wir wissen nicht, wie kompatibel das ist mit den verschiedensten Cloud-Speichern und es ist auch nicht so ratsam für uns, das Verschlüsselungsschema ständig zu ändern. Siehe: Use Base4k encoding to reduce encrypted file name length · Issue #2294 · cryptomator/cryptomator · GitHub
Wir könnten uns jetzt natürlich die Hände reiben und dann die Verantwortung auf den User oder das System schieben, wenn Dateinamen „zu lang“ werden (wer auch immer das definiert). Stattdessen haben wir uns für eine Name-Shortening-Methode entschieden, so dass Dateinamen, die „zu lang“ sind, über das beschriebene Verfahren „gekürzt“ werden (und der „lange Name“ wird dann in einer Datei ausgelagert). Warum haben wir uns an 255 orientiert? Weil das bei vielen Systemen nunmal eine Obergrenze zu sein scheint. Wir sind daher noch mal „sicher“ gegangen und haben die Schwelle auf 220 gesenkt, damit Cloud-Speicher im Zweifel noch ihre eigenen Zeichen dranpacken können im Konfliktfall.
Jetzt haben wir leider das Problem mit den Pfaden. Tresore können natürlich irgendwo beliebig auf dem Dateisystem liegen und Tresore sind nicht vom Speicherort abhängig (können überall verschoben werden). Gegen Dateipfadelimits haben wir zwar keine Maßnahmen im Verschlüsselungsschema, aber im Cryptomator-Client gibt es einen „Capability-Check", der überprüft, wie lang die Namen im Tresor tatsächlich sein dürfen. Dafür gibt’s dann in settings.json den Wert maxCleartextFilenameLength. Ist jetzt extrem technisch, aber wer sich dafür interessiert: From 1.5.x to 1.6.x - Migrating filenameLengthLimit
SO, und all diese Maßnahmen funktionieren auch zu 99%, so dass man sich als Anwender überhaupt nicht um die Länge von Dateinamen kümmern muss. Auf manchen Systemen kann es sein, dass man eine Fehlermeldung bekommt, wenn man Dateinamen hat, die „zu lang“ sind, aber dafür existiert dann auch eine klare Kommunikation.
Was ist mit den 1%? Ein bekanntes Beispiel ist HiDrive. Das Synchronisationstool verweigert den Dienst, wenn der Pfad zu lang ist. Aber leider erscheint der Fehler nicht in Schritt 3, sondern irgendwann im Nachhinein, so dass Cryptomator keine Chance hat zu erfahren, dass ein Limit überschritten wurde. Das ist tatsächlich noch ein ungelöstes Problem.
Und IRGENDWANN werden wir aus all der gewonnen Erfahrung das Verschlüsselungsschema an sich verbessern und kompatibler machen, aber das wird kein Schnellschuss, sondern ist eine langfristige Geschichte. Werden wir in Zukunft sicherlich kommunizieren, was da die Pläne sind.
@tobihagemann, @Rainer (und alle, die hier viel zeit investieren): vielen dank mal an dieser stelle für euren einsatz! als einfacher user finde ich es toll, was ihr leistet - sowohl technisch am produkt als auch kommunikativ in der community!
@Arthur_Dent: danke für deine frage. vielleicht magst du aber deine bemerkungen auf die wirklich guten antworten nochmal ansehen - und dir dabei überlegen, ob deine bemerkungen in der sache und in der form angemessen sind angesichts der information und hilfe, die dir mit viel einsatz und geduld gegeben worden ist …