FileVault es algo muy complicado que depende de una serie de variables para ejecutar sus operaciones, como el tamaño total de la unidad que está encriptando, el tipo de unidad (HDD [y RPM], SSD, etc.) y la cantidad de datos reales (y tipo de datos) almacenados en el disco.
Me encontré con un escenario hace un tiempo en el que tuve que desactivar FileVault para que ciertos procesos se inicien automáticamente en el momento del arranque sin que primero tenga que iniciar sesión. Tenía un HDD encriptado de 1TB que estaba lleno al 70%. FileVault tardó casi 4 DÍAS en descifrar este volumen. Entonces, sí, los procesos de FileVault definitivamente pueden tomar un tiempo.
En otra nota que no se refiere a FileVault en sí, sino a la barra de progreso en general, cuando actualicé de Mavericks a Yosemite, la barra de progreso se mantuvo en 99% diciendo "1 minuto restante" durante más de 2 horas.
Creo que esto es solo un manejo defectuoso de ciertos procesos GUI que los desarrolladores consideran no tan importante como las cosas que realmente afectan la funcionalidad normal del sistema, ya que es más una experiencia de usuario que se pone en segundo plano en lo que respecta al desarrollo y la mejora.
Por otra parte (y sé que esto no es el mismo nivel de código que el sistema operativo funciona sobre), pero si alguna vez intenta implementar una barra de progreso para las operaciones en bash(que aún no dispone de esta funcionalidad incorporada, tales como rsync, wget, etc. .), descubrirá que es increíblemente difícil estimar adecuadamente el "tiempo restante estimado" de ciertas operaciones de proceso.
Como he dicho antes, bashes un lenguaje de secuencias de comandos shell, y no un lenguaje de programación real, así que no puedo hablar en nombre de C, C++, etc, pero el comportamiento básico que he visto en bashpor barras de progreso es la siguiente (si esto ayuda a proporcionar cualquier visión):
- Tienes 10 procesos para ejecutar en un script.
- La barra de progreso se actualiza en incrementos del 10% después de que se completa cada proceso, de modo que después de que se complete el último proceso, su barra de progreso mostrará el 100%.
- Digamos que cada proceso debe tardar 1 minuto en completarse, por lo que el tiempo estimado general para toda la operación debe ser de 10 minutos.
- Ahora supongamos que el proceso # 9 encuentra algunas cosas inesperadas que tiene que manejar en el back-end detrás de escena (que la GUI no se puede configurar para actualizar y explicar en relación con el amplio alcance de las configuraciones individuales del sistema, porque eso realmente ralentizaría el desarrollo) .
- En lugar de tomar 1 minuto para ejecutar, el proceso # 9 termina tomando 10 minutos para resolver todo el desorden con el que tuvo que lidiar.
- Su barra de progreso estará atascada al 90% diciendo "1 minuto restante" durante 10 minutos.
- El resultado final es una operación que dice que tomará 10 minutos, pero en realidad, toma 20 minutos con una barra de progreso pegada al 90% durante la mitad del tiempo.
Lo anterior es solo la naturaleza de muchas implementaciones de barra de progreso y actualizaciones de usuario que he encontrado en la naturaleza, y espero que ayude a explicar la naturaleza de lo que encontró (solo en una escala más pequeña y mucho más simple).
Microsoft es horrible en esto, como ya lo sabe cualquier usuario de Windows, y obviamente han tomado muy pocos pasos (si es que los hay) para corregir o mejorar ese comportamiento. Desafortunadamente, a veces la respuesta es simplemente alejarse o tomar una siesta, y luego regresar y ver si algo realmente ha sucedido. Parece que esto es algo que tienen en común con Apple (o tal vez, como dije antes, es difícil explicar el tiempo estimado restante para tipos específicos de operaciones).
Es posible en su escenario específico que FileVault pensara que estaba casi terminado y luego se topó con algunas operaciones en ciertos bloques de archivos o algo que tomó un poco más de lo esperado originalmente, y la barra de progreso simplemente no se configuró para dar cuenta de esto.
