FileVault est une chose très délicate qui dépend d'un certain nombre de variables pour exécuter ses opérations, telles que la taille globale du disque que vous cryptez, le type de disque (HDD [et RPM], SSD, etc.), et la quantité de données réelles (et le type de données) stockées sur le disque.
J'ai rencontré un scénario il y a quelque temps où j'ai dû désactiver FileVault pour que certains processus se lancent automatiquement au démarrage sans que je doive d'abord me connecter. J'avais un disque dur crypté de 1 To qui était rempli à 70%. Il a fallu à FileVault près de 4 JOURS pour décrypter ce volume. Donc oui, les processus FileVault peuvent définitivement prendre du temps.
Sur une autre note concernant non pas FileVault lui-même, mais la barre de progression en général, lorsque j'ai mis à niveau de Mavericks à Yosemite, la barre de progression est restée à 99% en disant "1 minute restante" pendant plus de 2 heures.
Je pense qu'il s'agit soit d'un bogue dans la gestion de certains processus de l'interface graphique que les développeurs jugent pas aussi important comme des choses qui affectent réellement la fonctionnalité normale du système, car il s'agit plutôt d'une expérience utilisateur qui est mise en veilleuse en ce qui concerne le développement et l'amélioration.
Par ailleurs (et je sais que ce n'est pas le même niveau de code que celui utilisé par le système d'exploitation), si vous essayez d'implémenter une barre de progression pour les opérations dans l'application bash (qui n'ont pas déjà cette fonctionnalité intégrée, tels que rsync , wget etc.), vous découvrirez qu'il est incroyablement difficile d'estimer correctement le "temps estimé restant" de certaines opérations du processus.
Comme je l'ai déjà dit, bash est un langage de script shell et non un véritable langage de programmation. C , C++ etc., mais le comportement de base que j'ai vu dans bash pour les barres de progression est la suivante (si cela peut vous aider à comprendre) :
- Vous avez 10 processus à exécuter dans un script.
- La barre de progression se met à jour par incréments de 10 % après la fin de chaque processus, de sorte qu'après la fin du dernier processus, votre barre de progression affichera 100 %.
- Disons que chaque processus doit prendre 1 minute pour être achevé, de sorte que le temps global estimé pour l'ensemble de l'opération doit être de 10 minutes.
- Supposons maintenant que le processus n° 9 rencontre des éléments inattendus qu'il doit gérer en arrière-plan (que l'interface graphique ne peut pas être configurée pour mettre à jour et prendre en compte en ce qui concerne le large éventail de configurations de systèmes individuels, car cela ralentirait vraiment le développement).
- Au lieu de prendre 1 minute pour s'exécuter, le processus n° 9 finit par prendre 10 minutes afin de résoudre tout le désordre qu'il a dû gérer.
- Votre barre de progression sera bloquée à 90 % et indiquera "1 minute restante" pendant 10 minutes.
- Le résultat final est une opération qui dit prendre 10 minutes, mais qui en réalité prend 20 minutes avec une barre de progression bloquée à 90% pendant la moitié du temps.
Ce qui précède est simplement la nature de nombreuses implémentations de barres de progression et de mises à jour utilisateur que j'ai rencontrées dans la nature, et j'espère que cela aidera à expliquer la nature de ce que vous avez rencontré (juste à une échelle plus petite et beaucoup plus simple).
Microsoft est très mauvais dans ce domaine, comme le savent déjà tous les utilisateurs de Windows, et ils ont manifestement pris très peu de mesures (voire aucune) pour corriger ou améliorer ce comportement. Malheureusement, la solution consiste parfois à s'éloigner ou à faire une sieste, puis à revenir pour voir si quelque chose s'est passé. Il semble que ce soit une chose qu'ils ont en commun avec Apple (ou peut-être, comme je l'ai dit auparavant, il est juste difficile de tenir compte du temps restant estimé pour des types d'opérations spécifiques).
Il est possible dans votre scénario spécifique que FileVault pensait qu'il avait presque terminé et qu'il a ensuite rencontré des opérations sur certains blocs de fichiers ou quelque chose qui a pris un peu plus de temps que prévu initialement, et la barre de progression n'a tout simplement pas été configurée pour en tenir compte.
