# Error during updating vault (Cryptomator 1.5.3)

I get the following error when trying to update my vault. I am using Strato Hidrive. Since I tried the update, the Hidrive synchronisation tool tells me that it has an sync error due to a path name being too long (longer than 260 characters)

(Note I have manually changed my user name to “12345678” in the path that is shown in the error message)

org.cryptomator.cryptofs.migration.v7.InvalidOldFilenameException: Can't base32-decode 'BOLWBEYOYAQNFEFPPVU2UHX7UVKYY6TD4ARZDBJI6CLQAQLK67MFDAE6KXLI656XFMOKYEI6BKFPDXABOV2S4TBXY4G3U7RLZG3OL6QYJXKWJ4ZRIZFWTOE4S4HX4EWEFXKM5BX3HM======6AS56EKQ=' in file C:\Users\12345678\HiDrive\HiDrive\Home\HomeAktuell\d\FB\IQR4LCQEO4N2E5KCUHYTLCNL5T76FP\R4LZV5T22F6URPXGSV2EK3VP55M7Z3S2.lng
at org.cryptomator.cryptofs.migration.v7.FilePathMigration.getDecodedCiphertext(FilePathMigration.java:223)
at org.cryptomator.cryptofs.migration.v7.FilePathMigration.getNewInflatedName(FilePathMigration.java:209)
at org.cryptomator.cryptofs.migration.v7.FilePathMigration.migrate(FilePathMigration.java:122)
at org.cryptomator.cryptofs.migration.v7.MigratingVisitor.postVisitDirectory(MigratingVisitor.java:55)
at org.cryptomator.cryptofs.migration.v7.MigratingVisitor.postVisitDirectory(MigratingVisitor.java:17)
at java.base/java.nio.file.Files.walkFileTree(Unknown Source)
at org.cryptomator.cryptofs.migration.v7.Version7Migrator.migrateFileNames(Version7Migrator.java:119)
at org.cryptomator.cryptofs.migration.v7.Version7Migrator.migrate(Version7Migrator.java:101)
at org.cryptomator.cryptofs.migration.Migrators.migrate(Migrators.java:112)
at org.cryptomator.ui.migration.MigrationRunController.lambda$migrate$2(MigrationRunController.java:115)
at org.cryptomator.ui.common.Tasks$TaskImpl.call(Tasks.java:139) at javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: com.google.common.io.BaseEncoding$DecodingException: Unrecognized character: = at com.google.common.io.BaseEncoding.decode(BaseEncoding.java:219) at org.cryptomator.cryptofs.migration.v7.FilePathMigration.getDecodedCiphertext(FilePathMigration.java:221) ... 17 more Caused by: com.google.common.io.BaseEncoding$DecodingException: Unrecognized character: =
at com.google.common.io.BaseEncoding$Alphabet.decode(BaseEncoding.java:492) at com.google.common.io.BaseEncoding$StandardBaseEncoding.decodeTo(BaseEncoding.java:719)
... 18 more


Hi. See here. (German Post)
As you are using a strato service I assume you can read it. .
In short: as Cryptomator cannot know a path Limitation set by the sync client, you can either search for the long file name in the vault and shorten it (the unencrypted file), or you create a new vault, manually set a path limit in the json settings file, and copy your unencrypted files from the old vault into the new vault.

2 Likes

BOLWBEYOYAQNFEFPPVU2UHX7UVKYY6TD4ARZDBJI6CLQAQLK67MFDAE6KXLI656XFMOKYEI6BKFPDXABOV2S4TBXY4G3U7RLZG3OL6QYJXKWJ4ZRIZFWTOE4S4HX4EWEFXKM5BX3HM======6AS56EKQ= doesn’t make much sense. We had other cases where a .lng file contained invalid filenames but we still don’t know how and why this would happen.

Without the 6AS56EKQ= at the end, it makes much more sense. Please try the following:

1. Make a backup of C:\Users\12345678\HiDrive\HiDrive\Home\HomeAktuell\d\FB\IQR4LCQEO4N2E5KCUHYTLCNL5T76FP\R4LZV5T22F6URPXGSV2EK3VP55M7Z3S2.lng.
2. Edit the original file and delete 6AS56EKQ= at the end.
3. Try to upgrade the vault again.
1 Like

Thanks for your answer. However, the migration attempt has corrupted the vault (some directories have been empty when I tried to open the vault with an older cryptomator version).
I had to recreate the vault using a backup. This turned out to be rather tedious since I had to find all paths longer than 160 chars and shorten them (because the encrypted paths are longer than 256). It’s really annoying that the paths created by cryptomator are so much longer now - so for me the new version is a change to the worse.

Info: You can toggle the max length of encrypted files via a workaround

(I saw you participated in this thread, maybe you missed that. Or sid it not work for you?)

Yes, I’ve seen that. However, I haven’t changed the default value of 220 chars, and cryptomator still creates a path with 266 characters (the decrypted file name as such is 200 chars long, the created directories in the vault’s root directory 36, and the path of the root directory 30. So what would be the correct setting for a maximum total path length of 265?
And why are the created paths so much longer than in 1.4? I didn’t have any problems with long paths in the old version.

### A remark beforehand

One needs to differ between path length and filename length. These are related to each other, but not the same. Therefore each of them can cause problems.

This depends on how deep you stored your vault in the directory hierachy. The vault internal path length has a maximum of 268 characters (see here for more info). But i guess it might be more helpful to show a little…

### Example

Given:

• path to your vault is D:\path\to\MyVault (18 characters)
• all paths are limited to 241 characters and
• the file name length to 180.

The overall path length is calculated by path prefix + encrypted filename length x + rest where rest is the additional “overhead” for the internal vault structure (49 chars).

This leads to the linear system:

18 + 48 + x =< 241
x =< 180


The best solution is x=175 resulting in a file name length limit of 175 characters.

1 Like