Is there a technical reason? Once it is started you have to wait for days and it is extremely annoying.


It is not impossible in theory to create a "Cancel" button for FileVault.

Technically it is quite involved to create a "Cancel"-button. It is much more complex than for example creating a "Cancel"-button when you're copying a file.

Usually "Cancel"-buttons gets the computer to stop doing what it is doing. These are generally fairly easy to create. In the case of FileVault, it is not enough for the computer to stop doing what it is doing - it also has to undo everything it has done during the encryption process. That can be very time consuming and would need to be able to "survive" shutdowns of the computer.

As to why it was decided not to dedicate resources to creating the "Cancel"-button, there can be only speculation, as there's no official statement from Apple on the matter (which is not surprising).

  • Which can be simplified as "no technical reason at all". Yes it has to stop whatever it is doing and revert what ever done, yes it has to survive shutdowns, yes it can be time consuming (unless you cancelled at the first minutes of encryption)... But, all are already implemented. In filevault encrypt and decrypt are mutually opposite. So all missing is to get a state in cancellation point and continue from that. I think Apple should understand, even though rare, how much time loss it causes for its users. Anyhow, thanks a lot for the answer. – Mehmet Kaplan Mar 6 at 11:03
  • 1
    No, you're have that misunderstood. The stuff necessary to implement the Cancel button is not already implemented. "encrypt" and "decrypt" are not "mutually opposite" - that doesn't make sense at a technical level. – jksoegaard Mar 6 at 11:10
  • 1
    Also remember that you do not have to wait for days for the encryption to complete. You can just wipe the drive and restore from backup - that should be much quicker. Also you can use the computer while it is encrypting. – jksoegaard Mar 6 at 11:11
  • Encryption = opposite of decryption, because the algorithms are not one way while encrypting disks which means revertible which means they are opposite of each other. So not agreed. (And yes I already know that work can continue since filevault waits for idle times. But the initial question does not imply that I can not work.) – Mehmet Kaplan Mar 6 at 11:18
  • @MehmetKaplan I’m sorry, but technically it’s not correct. It might be the “layman’s understanding”, but it is not how things are in practice. The technical term for what you’re trying to describe is not opposite, but rather inverse - and it is not the case here. It is actually quite complex, and not just the matter of running an algorithm “backwards” or anything of the sort. The actual matter of decrypting the data on disk is actually the easiest part of the process - it’s the rest that is hard. I have studied cryptography and fs for years, and I can tell you this is by no means easy. – jksoegaard Mar 6 at 18:18

Technically there are three reasons to not do this:

  1. Encryption and decryption goes block by block and changes the data so you would have to program in code to halt that, then implement a partial reverse and go un-do the portion of the work that was already done.
  2. Everything you code, you have to test and the only code that has no bugs is the line of code you don't write.
  3. The social cost of adding complexity means documentation is longer, support is longer, troubleshooting is longer.

The alternative is just wipe your system, reinstall and restore from backup. For a pro, that takes maybe 15 minutes of time - plus some short waits since pros have installers cached or fast internet and can multitask. For a first time wipe and restore, you might take two hours max, plus waiting for the restore. If you're going to save days of wait and have a 2 hour to 20 minute fix, I'd say just abort the conversion is the winning move for anyone waiting days.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .