[1.5.0+] File name too long

Hey Community,

with Cryptomator 1.5.0 we updated our vault format to version 7. One of three key changes is the increased encrypted file name length. This can cause the problem, that encrypted files with a too long name don’t get synced to your cloud. This post describes how you can solve this problem and prevent it for the future, it does not describe the backgrounds. If your are interested, I refer to our docs and this thread.

That off the table, let’s get to the

Root of the Problem

To keep compatibility with all kind of filesystems and cloud storage providers, Cryptomator shortens the length of the encrypted file names. As long as this maximal file name length is bound to the storage location, the app can detect this limit and sets it locally for the vault. Unfortunately some cloud storage providers only implement the file name length limit in their sync client, which Cryptomator cannot detect.

Solution

The current workaround for this problem is to set the threshold manually.

For each vault the threshold is stored with the key "filenameLengthLimit" in the settings file of Cryptomator, settings.json. You can find it in the same location like the log files. This post explains how you can determine the correct value. But before changing it, you probably need to fix your vault.

Fix 1: Shorten your decrypted filenames

This method only works if no application depends on the naming of the too long files and if there aren’t too many.

Cryptomator preservers the time stamps (creation, modifaction and last access) of your files, because these are needed for proper synchronisation. You can use this for your benefit. You sync client should point to the encrypted file, which got too long. Remember the time stamps of these files and look inside your vault for files with long names and the same timestamps (e.g. by using a script). Once you found the decrypted file names inside your vault, shorten them until the client does not mope around anymore.

Afterwards, quit Cryptomator, open the settings file of Cryptomator and set the number of "filenameLengthLimit" key to the correct value for the vault in question.

Workaround 2: Migrate to a vault with shorter threshold

The other way is to create a fresh vault, change directly after creation the shortening threshold and then copy all files from the old vault to the new one.

This may be the more feasible approach if a lot of files needs to be renamed.

Final Remark

This filename length limit is only stored locally. This implies, that if you use the vault on another computer you need to apply this setting again to prevent sync problems there.

2 Likes

Would you post values for common Cloud Providers and sync Tools please.

  • onedrive
  • Dropbox
  • resilio sync
  • syncthing
  • nextcloud

Maybe we need a Matrix that combines providers and OS (Linux, Win,…)?

Would it be possible to store this info with the vault so that it moves with the vault (and hence even syncs to cloud automatically)? Even if this was only for the initial value during creation of the vault, it would still be very useful to avoid issues. Even better if it can store the updated values in case of modification.

What about the mobile clients?
I’ve created a new vault in my windows machine and changed the file size option to 200.
What about my mobile iOS client? Is there any need or possibility to configure this too?

Best Regards

Yes, but this would require a new vault format and hence a format migration. We constantly try to improve the format, and this specific question is considered for future vault format versions.


A need maybe. A possibility currently not.

So for my understanding if the filename isn‘t to long there should be no problem with storing files to the vault from the iOS application?
The worst case would be a file in the vault which doesn‘t sync to the Desktop and can only be deleted within the iOS application and should be stored again with a shorter name?

Yes.

For the first it depends how you integrate the cloud storage into the system, but yeah, the bottom line is that you won’t see those files & directories and they can only be deleted from other devices.

1 Like

I’ve been trying to get Cryptomator to work on a new Linux Mint machine I’ve added to my Nextcloud sync. I already have two PopOS machines and they never had this file length issue with Nextcloud/Cryptomator, which I don’t understand because the directory path is actually longer on those.

When I open the settings.json file to revise the filenameLengthLimit parameter on my Linux Mint machine, as instructed in this thread, it is already set to a value of -1 (which I don’t understand). I set the value to 150, as this is the value I set it to on my primary PopOS machine to compensate for the sync errors on my Mint machine. In all this troubleshooting, I’ve notice Cryptomator will occasionally overwrite the filenameLengthLimit value I’ve manually set, which is concerning since that could create the errors again in the future perhaps without me even catching it.

I have a couple questions:
What is meant by a filenameLengthLimit value of -1? (and why did Cryptomator set this value)
How do I know my manually-set filenameLengthLimit values won’t be overwritten again by Cryptomator on any of my synced machines?

I have used Cryptomator on/off for years and would like to continue to do so, but this file name length issue could end up being a deal killer, for me anyway. I hope a permanent solution is found soon.

PS - I’ve been doing a process of shortening the filenameLengthLimit parameter on my primary machine, then trying to sync the Mint machine to see if the length errors go away. I’ve done this down to a length limit of 125, which now prevents me from even moving some files into the new Cryptomator vault. There are about 7000 files in this vault and so renaming files isn’t feasible. If you have another solution, I’d love to hear it. Otherwise, I think Cryptomator is done for me in my current workflow.

This means that up to the point of viewing the settings file, for the specific vault the filename length limit still needs to bee determined (aka up to this point the vault was not unlocked).

If I look into our code, it is only overwritten if the value is set to -1 for a vault, see those lines in our code base.

It may be overwritten if your settings file contains errors (e.g. due to manual editing), because Cryptomator then falls back to a default settings file. Otherwise i cannot image how it is overwritten.


I don’t understand in your setup why you expect errors on PopOS, on most systems one hardly reaches the standard path and filename length limits. In this post i made a small example how to calculate the optimal file name length limit if you know the restrictions of the underlying filesystem.

© 2021 Skymatic GmbH • Privacy PolicyImpressum