FileVault es una cosa muy difícil que depende de una serie de variables para ejecutar sus operaciones, como el tamaño general de la unidad que está cifrando, el tipo de unidad (HDD [y RPM], SSD, etc.), y la cantidad de datos reales (y el tipo de datos) almacenados en la unidad.
Hace tiempo me encontré con un escenario en el que tuve que deshabilitar FileVault para que ciertos procesos se ejecutaran automáticamente en el momento del arranque sin que yo primero tuviera que iniciar sesión. Tenía un disco duro cifrado de 1 TB que estaba lleno al 70%. A FileVault le tomó casi 4 DÍAS para descifrar este volumen. Así que sí, los procesos de FileVault definitivamente pueden tomar un tiempo.
En otra nota relacionada con no con FileVault, sino con la barra de progreso en general, cuando actualicé 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 simplemente un manejo defectuoso de ciertos procesos GUI que los desarrolladores consideran no tan importantes como cosas que realmente afectan la funcionalidad normal del sistema, ya que es más una experiencia de usuario que se pone en el Quemador en retroceso en lo que respecta al desarrollo y la mejora.
Otra vez (y sé que este no es el mismo nivel de código en el que opera el sistema operativo), pero si alguna vez intentas implementar una barra de progreso para las operaciones en bash
(que aún no tiene esta funcionalidad incorporada) , como rsync
, wget
, etc.), descubrirá que es increíblemente difícil estimar adecuadamente el "tiempo estimado restante" de ciertas operaciones de proceso.
Como dije antes, bash
es un lenguaje de shell scripting, y no un lenguaje de programación real, por lo que no puedo hablar de C
, C++
, etc., pero el comportamiento básico que he visto en bash
para barras de progreso es el siguiente (si esto ayuda a proporcionar alguna información):
- Tienes 10 procesos para ejecutar en un script.
- La barra de progreso se actualiza en incrementos del 10% después de completar 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 total estimado para toda la operación debe ser de 10 minutos.
- Ahora digamos que el proceso # 9 encuentra algunas cosas inesperadas que tiene que manejar en el backend detrás de la escena (que la GUI no puede configurarse para actualizarse y tener en cuenta el amplio alcance de las configuraciones individuales del sistema, porque eso realmente ralentizaría desarrollo hacia abajo).
- En lugar de tomar 1 minuto para ejecutarse, el proceso # 9 termina tomando 10 minutos para resolver todo el lío con el que tuvo que lidiar.
- Su barra de progreso se quedará bloqueada 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 bloqueada al 90% durante la mitad del tiempo.
Lo anterior es solo la naturaleza de muchas implementaciones de barra de progreso y actualización de usuario que he encontrado en la naturaleza, y espero que ayude a explicar la naturaleza de lo que encontraste (solo en una escala más pequeña y mucho más simple). p>
Microsoft es horrible con esto, ya que cualquier usuario de Windows ya lo sabe, y obviamente han tomado muy pocos pasos (o ninguno) 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 quizás, como dije antes, es difícil tener en cuenta el tiempo restante restante para tipos específicos de operaciones).
Es posible en su escenario específico que FileVault pensó que estaba casi terminado y luego se ejecutó en 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 estaba configurada para dar cuenta de esto.