Hi,
I am seeing files with long names in Japanese and Chinese characters not showing up in File Explorer after mounting the vault using WinFSP (FUSE). For example, if I create a text file in the vault and name it あああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ.txt (“あ” x83 times), the file will remain visible, but as soon as I add another “あ” into the file name (84 in total), the file will disappear after a refresh.
I can still see the encrypted file, so the data is intact, just not showing up anymore. One strange behavior resulting from this is not being able to delete any directory that contains such a file.
Interestingly, if I try to rename the file with lots of ASCII characters, File Explorer will automatically truncate the name to about 240 characters, so this usually isn’t a problem.
Directories also suffer from the same issue, but you can still navigate to it by directly entering the path in the navigation bar. This requires prior knowledge of the existence and the name of the invisible directory though.
I though this might be a bug of WinFSP itself, so I did a bit more investigation.
I installed WinFSP on its own in a freshly created Win10 virtual machine and tried to reproduce the issue but couldn’t. It is able to handle names much longer (I tried 200 “あ”) without problem.
I then installed Cryptomator on the virtual machine as well, and the issue persists.
I believe there must be a bug in how WinFSP is implemented by Cryptomator.
I can confirm on my Windows 11 machine this behaviour and created a ticket on our issue tracker:
It seems to be a WinFsp issue: We are not using the WinFsp API, but the FUSE API and its Winfsp implementation. (a difference!) I’ll escalate the issue to the winfsp repo.