Whenever I try to find the size of a file in linux I usually go
du -s file. However the result for decrypted files size is 0. Therefore I usually open a file explorer (Nautilus for example) and find there what is the file size. I don’t know how Nautilus can find it out while my
du is not working.
After spending quite a while online and reading manuals, I couldn’t find an explanation of how file decryption works in storage basis. Hence I would appreciate if you could clarify the following questions:
- Why Cryptomator doesn’t require extra file space for the decrypted files? For example, I couldn’t find any cache directories (for desktop version without referencing to cloud storage).
- Decrypted files are not symbolic or hard links to other files, but I have never seen 0 file size (obviously I am not a computer expert).
Welcome to the Cryptomator community ,
Cryptomator encrypts data on the fly, i.e. on every access, to exactly avoid storing your data unencrypted on storage. Still, caching is used to increase performance, but the caches are kept in volatile memory only, specifically in the memory assigned to the Cryptomator process by your OS.
What you see is just a decrypted view of your encrypted files. This is possible because Cryptomator implements its own filesystem, which acts as a translation layer between encrypted storage and decrypted view.
I don’t know why the du tool shows a file size of 0, it may be related to the fact, that Cryptomator uses FUSE to integrate its filesystem in the surrounding os.
du -b file,
du -bs file or
du -bhs file should work
I just learned a bunch of stuff today. Thank you both for your time and knowledge
Im having the same issue on linux.
ls -s, du -s report 0.
But ls -l does report the expected size.
I tried with gocryptfs and encfs and they report the correct sizes (ls and du). They present a completely normal mount to the system, meanwhile cryptomator presents some ‘magic’ files of 0 size (just like those in /proc/).
This behaviour breaks compatibility with scripts and other applications which rely on querying file sizes.
Hey and welcome to the Cryptomator Community ,
I can reproduce your described behavior using FUSE to mount the vault in Manjaro.
What does the
-s parameter do, from the man page:
print the allocated size of each file, in blocks.
The interesting thing is, that a file in the Cryptomator vault returns amount of block =
0 for each file:
~/cryptomator >>> stat bar.txt
Size: 14654 Blocks: 0 IO Block: 4096 regular file
Device: 41h/65d Inode: 9 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ julian) Gid: ( 1000/ julian)
Access: 2021-08-23 14:16:06.671911348 +0200
Modify: 2020-07-12 14:04:09.084661000 +0200
Change: 2020-07-12 14:04:09.084661000 +0200
This is also reproducible using the MirroringFuseMountTest. It is interesting too, that Veracrypt (which also uses fuse to mount the vault content into the system) displays for every file
Blocks: 8 which results in
ls -s or
du -s of each file =
~/veracrypt >>> stat foo.txt
Size: 589 Blocks: 8 IO Block: 4096 regular file
Device: fe02h/65026d Inode: 23 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ julian) Gid: ( 1000/ julian)
Access: 2021-06-13 15:16:24.000000000 +0200
Modify: 2020-10-12 11:16:39.000000000 +0200
Change: 2020-10-12 11:16:39.000000000 +0200
du -s *
yeah. Thats the reason. I get the same stats. Size is good but Allocated Block size is 0 so applications like Thunar (file manager) fail whenever im accessing the decrypted directory. Its should at least fake it otherwise applications get confused.