Verzeichnisname zu lang - Synchronisationsfehler

Hallo Community,

ich habe folgendes Problem: Ich habe Dateien mit Cryptomator verschlüsselt und möchte diese in die MagentaCloud (Cloud der Telekom) hochladen. Dies hat soweit bisher auch gut funktioniert.

Nun, nachdem ich ein paar neue Dateien hinzugefügt hatte, erscheint allerdings eine Fehlermeldung von meiner Cloudsoftware: Der Upload eines Verzeichnisses sei nicht möglich, da der Datei/Verzeichnisname zu lang ist.
Der Lösungsvorschlag meines Cloudanbieters lautet, den Dateinamen zu kürzen.

Jetzt allerdings meine Frage: Ist dies der richtige Lösungsweg bzw. kann Cryptomator mit derselben Datei, allerdings einem veränderten Namen überhaupt noch etwas anfangen? Oder kennt ihr einen alternativen Lösungsweg, wie man unter Windows Dateien mit einem Dateinamen über 260 Zeichen zulassen kann bzw. dieses Problem in Cryptomator beheben kann?

Danke für eure Hilfe :slight_smile:

Kannst du genauer sagen, um was für einen Dateinamen es sich handelt? Cryptomator kürzt bereits Dateinamen, um genau diesem Problem vorzubeugen. Ggf. liegt das Limit in MagentaCloud ja weit unter den sonst üblichen Grenzen.

Hab dir mal ein Screenshot davon gemacht Dateiname_1|690x56

Das is kürzer als 260 Zeichen. Cryptomator kürzt Dateinamen, die zu lang werden.

Stimmt, habe soeben nachgezählt :thinking: Habe die Datei jetzt einmal mit Strg + X auf den Desktop verschoben und wieder in das Verzeichnis zurückverschoben, jetzt wurde sie tatsächlich synchronisiert. Allerdings zeigt mir Windows jetzt an, dass die Datei, die vorher noch eine Größe von 16kb hatte, jetzt eine Größe von 0kb hat. Woran liedgt das?

Hallo, das Problem tauchte bei mir in gleicher Form auf.

Weder das zeitweise verschieben noch eine komplette Neusynchronisation (alle Dateien aus Synchronisationsverzeichnis löschen, Safe schließen und wieder öffnen, Dateien neu aufgespielt) hat eine Verbesserung gebracht.

Problem scheint die Limitierung der Pfadlänge von Windows auf 260 Zeichen zu sein. Die Datei selbst hat 193 Zeichen. Der gesamte Pfad hat 74 Zeichen, zusammen also 193 + 74 = 267 Zeichen. Das scheint für MagentaCloud ein Problem zu sein. Kann man das beheben?

Fehlermeldung der Desktopversion des MagentaCloud Synchronisationstool für Windows, Dateiversion 6.1.0.12:

Fehler #: 1
Urache: Zu langer Verzeichnisname
Datei- oder Verzeichnisname: o_9x9Te9IU4233qk47B8Vk7FjJ-N5fLMsk1oQrpVjk0yxtBp3yaYAMrNjg_ts61AaxqacoxBhFH6xQgEY5Sbi309Ye7ofBfCRbo0UZPTWM-nVeyYtCqww7ghDK2mC_SGPU3LZEY7TOUWU3cRHeWbSxSHJrtYUBghCejyiFyDaRhxh2CO1JGjtZu1yGc=.c9r
Pfad zu Datei oder Verzeichnis:
D:\Cloud\MagentaCLOUD\Crypto\MyFiles\d\MF\PBTHWWXSKS2YE5IZPG5GCGPI3TCELM
Hilfeartikel: https://cloud.telekom-dienste.de/hilfe/synchronisieren/lange-dateipfade

Hi, habe das Problem auch nachdem ich jetzt auf 1.5 upgedated habe. Es wäre super gewesen wenn man für die Dateinamens - Länge eine Option hätte. So werde ich versuchen einen neuen Container anzulegen und die Dateien da rein zu kopieren. Ärgerlich für alle die die Daten nicht noch woanders haben. Schwer verständlich warum man sich nicht an die “Normen” hält.

Tun wir:

https://docs.microsoft.com/de-de/windows/win32/fileio/filesystem-functionality-comparison#limits

Edit: Ach so, du meintest die Telekom. Ja die haben es tatsächlich nicht so mit Standards, hab da damals in meiner Beraterzeit auch so einige willkürlich gewählte Werte in Datenbanken etc mitbekommen.

Siehe soeben von mir geteilter Link: Das ist ein “Volksglaube”. Pfade können auf Windows deutlich länger sein. 2016, als wir Cryptomator gestartet haben, haben wir uns tatsächlich selbst noch daran gehalten, was aber damals schon nicht an Windows lag, sondern an OneDrive, welches damals tatsächlich ein derartiges Pfadlängenlimit hatte. Hat MS dann irgendwann nach einigen User-Protesten selbst behoben.

Habe die Thematik jetzt mit den Programm Treesize überprüft, nach diesem Beispiel:
https://www.jam-software.de/treesize/pfade_ueber_255_zeichen.shtml

Folgendes Vorgehen:
Ich synchronisiere von Lauferk X mehrere Pfade über Cryptomator in einen Tresor, auch auf Laufwerk X.
Resultat:

  • Die eigentlichen Verzeichnisse auf Laufwerk X sind allesamt <260 Zeichen
  • Nur im Verzeichnis mit dem Cryptomator-Tresor gibt es Verzeichnisnamen >260 Zeichen.

Das Problem tritt erst seit der Verwendung von Cryptomator 1.5.0 auf, vorher ging es problemlos.
Wäre es nicht möglich eine Art “Abwärtskompatibilität” für solche Problemfälle zu schaffen?

Danke,

Wir haben in den letzten Tagen viele Nutzerrückmeldungen über diese Thematik erhalten und arbeiten an einem Update, dass dieses Problem angeht:

<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:

  1. 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?

  2. 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.


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.

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.

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

1 Like

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.

:warning: 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:

  1. Neuen Tresor im Zielverzeichnis erstellen
  2. Dateinamelängenlimit einstellen (siehe unten)
  3. 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
    },
3 Likes

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.

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?

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.

1 Like

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? :thinking:

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?

© 2020 Skymatic GmbH • Privacy PolicyImpressum