Decrypted file size

Help Desktop App
1

Hi,

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:

  1. 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).
  2. 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).

Thank you!

2

Welcome to the Cryptomator community :slightly_smiling_face: ,

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.

2 Likes
3

du -b file, du -bs file or du -bhs file should work

2 Likes
4

I just learned a bunch of stuff today. Thank you both for your time and knowledge

5

Hello

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.

6

Hey and welcome to the Cryptomator Community :slightly_smiling_face:,

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
  File: 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
 Birth: -

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 = 4

~/veracrypt >>> stat foo.txt
  File: 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
 Birth: -

du -s *                                
4	foo.txt
4	bar.txt
4	baz.txt

:thinking:

7

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.