-
-
Notifications
You must be signed in to change notification settings - Fork 981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibility to set maximum length of encrypted path and file name for a new vault (configurable shorteningThreshold) #1209
Comments
We have created an article in our forum which describes the problem and states a workaround by editing direclty the |
With vault format 8 the filename length limit will be part of the vault configuration and not system dependent anymore. (see cryptomator/cryptofs#95) Depends on #1454 |
Due to a bug reported in #1617, we had to change the specificiation fo the fileNameLength limit. It will refer now to to cleartext names now, which makes it easier for users to understand what files are affected. For more info, look into the linked issue. |
This feature is planned for 1.7.0 |
This feature is rescheduled to 1.8.0 |
Cryptomator's now on version 1.10. Has this feature been included in the app or has it been further delayed? |
This feature is implemented since 1.10.0, see #2266 |
Summary
Upon creation of a new vault a maximum path length of encrypted path and file name (target) can be entered (optionally) - for some cloud providers this number needs to be 260. This vault cannot be opened with older versions of Cryptomator.
Motivation
With vault format 7 there is often the issue of too long filenames with some cloud providers. They limit the maximum path and filename length to 260 based on old Microsoft spec. Encrypted path and filename is longer then original path and filename. So the limit of 260 might be exceeded although original path and filename are well below 260. A user cannot foresee that a file will exceed the 260 char limit.
Problems with such cloud providers can be avoided. Usability will increase. Number of files the will use the algorithm to shorten encrypted filename is minimized - therfore increases performance.
Considered Alternatives
Manual activity by user: error analysis and handling after sync errors occur and manual renaming of files. However, this is time consuming and sometimes this not possible if path and filenames are too long which have been automatically created by other software.
Additional Context
Discussions and further information: https://community.cryptomator.org/t/verzeichnisname-zu-lang-synchronisationsfehler/4404/21
The text was updated successfully, but these errors were encountered: