I'm not sure about a formal name but I can comment on your other questions. A lot depends on the level at which you do the encryption. There are three main approaches I'm aware of:
- The disk data itself is encrypted,
- The file system encrypts data stored in it but is itself stored in plain text on the disk (e.g. CryFS),
- Individual files are encrypted but directory structure and file system level meta data (size, timestamps, etc) is not (e.g. EncFS). This is basically what ransomware does.
Generally speaking, none of these approaches encrypt an entire disk worth of data as one long cipher text. They break it down to some degree, whether by sector (in the case of 1), by file (in the case of 3) or arbitrary chunks (in the case of 3). There's a practical reason for this: all the cipher text within an encryption unit (block, sector, chunk, file, etc.) should change if any part of it is changed. If your entire disk were one encryption block then simply viewing a file (modifying the access time) could result in the entire disk being rewritten.
You can generally assume that an OS will put some metadata onto a disk as soon as it's mounted (and maybe even periodically) so the cipher text will change from day to day. However, it won't be the entire disk that changes, just certain portions that become predictable to a diligent observer after a while.
Now...the disappearance of 100MB of clear text coinciding with the appearance of 100+MB (a sane disk encryption system will have data authentication overhead) of ciphertext is a pretty strong indicator that you encrypted the sensitive file. There are things that will complicate this depending on the exact scheme used. First, the amount of change on the encrypted partition will be rounded to the smallest encryption unit (which can be quite large). Second, if a scheme does not store your new file contiguously (is fragmented, intentionally or unintentionally) then significantly more than 100MB of new ciphertext will be created/changed. The last factor can make it much more doubtful whether the sensitive file has just been encrypted but does not apply at all to scheme #3.
Of course, if the attacker is aware of the scheme you're using and are only missing the key then they'll know with high confidence that you simply moved the file. The only way I can think of that would make it doubtful whether you still have the file is if you were able to store the file in a different form by:
- compressing it to reduce the written size
- padding it arbitrarily to increase the size
You would still have the timing signal though. That is more an operational issue than anything. You have to avoid unlikely coincidences like that if you are to be able to meaningfully use the encrypted partition in a hostile environment. Even if the file weren't on the other partition, the release of a controversial file online coinciding with the appearance of a similar amount of cipher text on your partition is quite revealing.
You could have a script randomly creating, deleting and touching files, rotating encryption IVs, moving data across block boundaries, etc so you end up with a few hundred MB of changed ciphertext daily without anything really happening from your perspective. If you're clever enough you could have this system gradually create an opening for your sensitive file through various blank hidden files and then slowly "garbage collect" this back into one contiguous file again over time. You'd have to be exceedingly clever to have this process not become a side channel for information about the clear text of the partition though.
P.S.: If someone has a way of extracting an entire disk image on a regular basis without your knowledge it's probably just as feasible for them to replace it with a file system that's more convenient for them (think "decrypts on mounting then only pretends to encrypt thereafter") just as discreetly.