Cryptomator 1.5.2 and later
Cryptomator has been updated that restores and improves compatibility of vaults stored in locations that limit file path or filename lengths. The issues mentioned below have been solved. Thank you all for your patience!
If an automatic migration is impossible due to these length limitations, Cryptomator will inform you about them and suggest a manual migration.
Cryptomator 1.5.0/1.5.1
After some major changes with the new Cryptomator 1.5 release, we noticed two incompatibilities that we’d like to inform you about. If you are affected by one of the points below, please do not update to Cryptomator 1.5 yet until we delivered a new update. If you have already updated and ran into issues, check out the links below.
- Vaults located on WebDAV drives on Windows
- Vaults located on eCryptfs-encrypted volumes (has workaround, follow link)
- https://github.com/cryptomator/cryptomator/issues/1116
- Note: No issues reported with LUKS-encrypted volumes
If you are not affected by these scenarios, you can continue with a vault upgrade. You are advised to make backups though!
Technical Details
With the new vault format 7, we increased the “long filename” threshold from 129 to 220 (ciphertext length), which is still below 255 to maximize compatibility. However, the file path length might be longer and this can’t be put under a threshold since a vault can be located anywhere on any device.
That’s why we’ve introduced a FileSystemCapabilityChecker
that checks if long filenames and long file paths are supported on the underlying file system. E.g., in Cryptomator 1.5.0, it checked if a file path with length 400 is compatible. In Cryptomator 1.5.1, we relaxed this value to 300.
The capability checker caused issues like “unable to upgrade” or “vault is being opened in read-only mode”. It seemed to cause more issues than being a useful feature. We are still discussing solutions, please stay tuned!
Main discussion will be here: https://github.com/cryptomator/cryptofs/issues/77