Every long file name accessed/created/copied/moved generates approximate 3 files and 6 folders in the vault's storage's `/m/` folder.

[buddydvd]

Basic Info

I'm using macOS in version 10.14.4. I'm running Cryptomator in version 1.4.9.

Description

Here's an example that shows how extraneous files and folders get created within a vault's storage's /m/ folder:

1. Create an empty vault.
2. Unlock the vault.
3. List the content of the vault's storage folder.
4. Create an empty text file and save it to the root folder of the vault with the following file name: 0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz.txt
5. List the content of the vault's storage folder.

Expected

I expect to see one .lng file in a newly created doubly nested folder.

Actual

I actually saw three .lng files in three newly created doubly nested folders.

Terminal Log

Davids-MacBook-Pro:test_vault_4 david$ tree
.
├── d
│   └── PV
│       └── HG6MYJAKHZ2GTPTRYGYVK35HNNZOYQ
├── m
├── masterkey.cryptomator
└── masterkey.cryptomator.bkup

4 directories, 2 files
Davids-MacBook-Pro:test_vault_4 david$ touch /Volumes/WRdujCzVRdKQ_0/0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz.txt
Davids-MacBook-Pro:test_vault_4 david$ tree
.
├── d
│   └── PV
│       └── HG6MYJAKHZ2GTPTRYGYVK35HNNZOYQ
│           └── BEKHY2XVUJPRRNESGIZOABYQTOH5EQKG.lng
├── m
│   ├── BE
│   │   └── KH
│   │       └── BEKHY2XVUJPRRNESGIZOABYQTOH5EQKG.lng
│   ├── H2
│   │   └── W5
│   │       └── H2W5QASJPSB4333DGYRSTDEM6IY6C5GE.lng
│   └── JS
│       └── 2T
│           └── JS2TLPOQTKJ5YEGV7OZ5WUSA7ADHVBWU.lng
├── masterkey.cryptomator
└── masterkey.cryptomator.bkup

10 directories, 6 files
Davids-MacBook-Pro:test_vault_4 david$ cat m/BE/KH/BEKHY2XVUJPRRNESGIZOABYQTOH5EQKG.lng 
5BMCE5INI6B4VDVQGZQ2ORWSEHJ46P3APFVBPWL6U2R7AV5C2LAOGNVBXOXYI65Q2EDOODKZRJ5TLXVTVIED35ZIGG5RMIZIWZCT55NUW5KLWFVJLLHJH5V76OJVQYI6YCM25NJ4OQN45NDDATAQ====
Davids-MacBook-Pro:test_vault_4 david$ cat m/H2/W5/H2W5QASJPSB4333DGYRSTDEM6IY6C5GE.lng 
05BMCE5INI6B4VDVQGZQ2ORWSEHJ46P3APFVBPWL6U2R7AV5C2LAOGNVBXOXYI65Q2EDOODKZRJ5TLXVTVIED35ZIGG5RMIZIWZCT55NUW5KLWFVJLLHJH5V76OJVQYI6YCM25NJ4OQN45NDDATAQ====
Davids-MacBook-Pro:test_vault_4 david$ cat m/JS/2T/JS2TLPOQTKJ5YEGV7OZ5WUSA7ADHVBWU.lng 
1S5BMCE5INI6B4VDVQGZQ2ORWSEHJ46P3APFVBPWL6U2R7AV5C2LAOGNVBXOXYI65Q2EDOODKZRJ5TLXVTVIED35ZIGG5RMIZIWZCT55NUW5KLWFVJLLHJH5V76OJVQYI6YCM25NJ4OQN45NDDATAQ====

Note

This is a really undesirable behavior. I encountered this issue while copying a long list of files with long file names in to a vault. Each file with long file name copied into a vault yields six metadata folders and three metadata .lng files. This is many more files and folders than described in the documentation. My reading of cryptofs's source code indicates the bug originates here:

https://github.com/cryptomator/cryptofs/blob/b29c89b43e75c044b0d5969c8fe58cae1e6c26b6/src/main/java/org/cryptomator/cryptofs/CryptoPathMapper.java#L81-L103

For every file with long file name that gets accessed, created, copied, or moved, cryptofs creates three .lng metadata files because the code attempts to check if that file name is a directory, a symlink, or a file.

[overheadhunter]

Damn, I saw this coming 3 years ago:

https://github.com/cryptomator/cryptofs/blob/20e00a06f72a8f4f4f2790a0fe39a555e2b2f5ba/src/main/java/org/cryptomator/cryptofs/LongFileNameProvider.java#L81-L82