Why so many files?

This question addresses all platforms I guess, but I the current issue I have with the Desktop App (Mac).

Cryptomator creates lots of files – far more than the original decrypted amount of files. I have a project that I organize with a lightweight documents management tool (EagleFiler). This is the outline of the files I have:

290 Pictures
85 Files
3 Movies
11 Microsoft-Word(2007)-Documents
18 Microsoft-Word-Documents
38 Folders
180 PDFs
13 RTF-Documents
4 Text Files

=> 642 Objects

EagleFinder after start synchronizes its internal database with the file base and touches the files (for whatever reason). This leads to 2009 file changes in Cryptomator. And that takes several minutes on a fast internet connection to synchronize with GoogleDrive.

What is the reason that the number of files is more than 3 times as high compared to the file system? BTW I assume that not even all files have been touched so that the actual ratio is even worse than 2009 / 642.

Hi tom.
Asuming you are native German, please refer to the manual for detailed information of crypto mechanics. There is also the explanation why one decrypted file leads to various encrypted files and folder structure.
https://cryptomator.org/de/architecture/

If my suggestion is wrong, I think there’s an English version as well on the main page.

1 Like

Got it. Part of the security concept.

Just like to add: Yes, part of it is the security architecture. Especially, if you have a lot of files with long filenames, they’re getting shortened, which creates additional metadata files in the m directory.

Another thing to consider on macOS is: Since we’re using WebDAV as the virtual filesystem, macOS treats it like a generic/network volume. It’s using the AppleDouble format for files that need it. We can’t influence this directly and it’s just how Finder handles WebDAV. But it’s actually quite important to consider when switching to FUSE in the future.

macOS revived the use of AppleDouble; on file systems such as NFS and WebDAV that don’t natively support resource forks, Finder information, or extended attributes, that information is stored in AppleDouble format, with the second file having a name generated by prepending “._” to the name of the first file (thus, this information acts as a hidden file when viewed from a non-Apple Unix-based operating system).

@tobihagemann good info. Because I still was in doubt why the files where more than tripled. So apples meta-info files are also stored in the cloud. On the other hand the benefit is that this data is restored after decryption, right? And may be lost when switching to FUSE?

Yes, they’re “restored” after decryption. That’s actually the beauty of transparent encryption. Finder doesn’t know that the virtual drive is encrypted underneath.

We actually don’t know yet what happens after switching to FUSE. But we’re definitely keeping this fact in mind when doing the transition.

1 Like