This project has moved. For the latest updates, please go here.

Defer/Resume Container

Topics: Feature Requests, Users Discussion
Jul 14, 2015 at 2:02 PM
I see that there is a Resume interrupted process in the Volume menu. Is it possible for this to somehow be applied to container volumes and not strictly partitions? I often create 500+ gb containers that can take many hours to fully encrypt. It would be really nice to be able to defer those and resume them later.

Furthermore how does this work on non-system partitions? Do you simply abort the encryption process and it automatically allows you to resume it later?
Coordinator
Jul 14, 2015 at 2:40 PM
Defer/Resume applies only to in-place encryption of non system partitions.

When creating an empty encrypted partition or when creating an empty file container, no pause/defer is offered because no encryption is actually taking place and VeraCrypt spends all the time writing random data to the partition or the file container (the size of the file is determined by how much data you write, so stopping before the end will result in a smaller file size).

For file container, one could argue that we can just stop, leaving the file with smaller size and then resume by continue writing more random data to it making its size expand again. This is indeed a possibility by I'm not sure it is worth the effort since it is better to wait for the file container to be created to have full confidence on its security and most users will wait the necessary time.

In the case of in-place encryption, we store in the partition the encryption state so that if the operation is stopped, the next time we can resume it from where it stopped.
Jul 14, 2015 at 3:18 PM
idrassi wrote:
Defer/Resume applies only to in-place encryption of non system partitions.

When creating an empty encrypted partition or when creating an empty file container, no pause/defer is offered because no encryption is actually taking place and VeraCrypt spends all the time writing random data to the partition or the file container (the size of the file is determined by how much data you write, so stopping before the end will result in a smaller file size).

For file container, one could argue that we can just stop, leaving the file with smaller size and then resume by continue writing more random data to it making its size expand again. This is indeed a possibility by I'm not sure it is worth the effort since it is better to wait for the file container to be created to have full confidence on its security and most users will wait the necessary time.

In the case of in-place encryption, we store in the partition the encryption state so that if the operation is stopped, the next time we can resume it from where it stopped.
Ah thanks for the clarification. While I do agree that most users creating small containers would wait, the main issue here comes in the form of large containers. I know for example I've created 500gb containers that took hours, and sometimes it would be better to be able to defer the process.

As far as stopping a container creation process before it finishes, as it stands right now if you stop it you have to restart it all over. If you're creating a container that will take 12 hours to create, it would be incredibly annoying to have to restart the process because you couldn't defer it and you had to shut the computer down. (A situation I've actually been in due to storms and unreliable mains power)

I would like to suggest this as a potential future feature if possible, as the main issue might not seem like an issue right now and I'm sure didn't seem like an issue back when TC was originally created due to the fact that most people didn't deal in large data. Every time I hear about TC/VC people talk about at most containers of 2-5gb. I deal in containers of 250-1000gb. The larger the data, the more time to create. Therefore the more a defer option would be useful. It doesn't even have to come in the form of a true defer, just giving some form of option would be nice.

Though I suppose in a way I can answer my own "feature" request given that with the volume expander this is already somewhat possible. Though that is a somewhat complicated way of going about it. My argument is from a practical standpoint people are simply getting more and more data and the data itself is becoming larger and larger. It would certainly be something to consider for the future, given that fact.

Also I was just encrypting a external hard drive and decided to try the resume process and it locked up veracrypt, after about 20 minutes I assumed it wasn't going to work and had to kill it. This was halfway through and it had already been going for nearly 14 hours. Luckily in this case I wasn't particularly bothered by the situation. I just wanted to test it. So I'm not sure that it actually works.
Jul 14, 2015 at 4:47 PM
idrassi wrote:
Defer/Resume applies only to in-place encryption of non system partitions.
Are the options Defer/Resume grayed-out when performing disk/partition non-system encryption when not performing in-place encryption?
Coordinator
Jul 14, 2015 at 9:02 PM
@Enigma2Illusion:
Other than in-place encryption, the only available button is "Abort" as shown in the screenshot below.

@TGS:
Thanks for the detailed feedback. I understand your point about the growing requirement for containers size. This is to be added to the features list although its priority will be low for now.

Concerning the resume process taking too much time, I have done several enhancement to this in the latest 1.12-BETA and now things behaves better especially since it is possible to directly select the drive from where you want to resume encryption/decryption. Also, the 1.12-BETA introduces a new feature called PIM that makes it possible to have quicker mount times (and thus quicker resume times) for those using strong passwords (more information here). The 1.12-BETA is available here.

VeraCrypNoSystemEncryption