Oui. La problématique est la suivante -->
- aucune partition n'existe sur un disque. Càd. aucune "balise" ne marque "tel bloc" comme étant le bloc de départ d'une partition et "tel bloc" comme étant son bloc de fin. C'est un descripteur présent dans la table GPT des 33 premiers blocs du disque qui décrit "virtuellement" la partition du disque. Cette table GPT est lue par le kernel (le moteur du Système démarré) > et c'est le kernel qui convertit les descriptions des descripteurs en "appareils logiques du disque".
- par contre > ce qui existe sur le disque --> ce sont les écritures : soit du système de fichiers (qui est le transformateur d'un espace de partition en volume) > soit des fichiers (gérés comme objets lisibles du volume par le système de fichiers). Ces écritures utilisent le bloc (de 512 octets en général) comme la plus petite unité signifiante pour l'inscription de fichiers. Or parmi tous ces blocs écrits > il y en a un qui a un privilège absolu et qu'on peut donc appeler le "super-bloc" : c'est le bloc initial sur lequel se trouve écrit le header (en-tête) du système de fichiers. C'est donc le bloc d'ancrage ou bloc origine des écritures du système de fichiers (formateur du volume).
- pour que ce super-bloc du système de fichiers puisse être pris en charge par le kernel > il faut de toute nécessité qu'il corresponde au 1er bloc d'une partition (virtuelle) décrite par un descripteur de la GPT. Ainsi : le kernel lisant tel descripteur qui lui fait "construire en appareil logique" une partition > va au 1er bloc de cette partition sur le disque > et si ce 1er bloc de la partition décrite par le descripteur coïncide avec le "super-bloc" d'un système de fichiers => hop ! le système de fichiers initié à partir du "super-bloc" se trouve "pris en charge" (chargé) par le kernel et hop ! le kernel monte le volume défini ou formé par ledit système de fichiers (à condition que le système de fichiers soit valide = sans erreurs).
En conséquence de cette problématique esquissée : notre
problème théorique consiste à
conjecturer que
tel bloc (défini par son
n° de bloc dans la
GPT) => serait bien le
super-bloc où le
système de fichiers qui formait ton volume aurait son
header. Si on pouvait
déterminer avec certitude quel est ce
n° de
bloc du disque =
super-bloc du système de fichiers => alors
recréer un descripteur GPT décrivant "virtuellement" une
partition dont le
1er bloc serait ce
super-bloc --> n'est qu'une question de
technique de commande du
terminal sans aucune difficulté formelle. Mais ce
n° de
bloc =
super-bloc du système de fichiers => rien n'assure quel il est. Voilà l'ennui...
- problème annexe : une partition se trouve décrite conformément à un type par le descripteur GPT (par exemple : type "Apple_HFS" ou type "Apple_CoreStorage"). Pour que le kernel lisant un descripteur GPT et construisant un appareil logique de partition d'après lui => puisse prendre en charge le 1er bloc décrit (identique au super-bloc -supposons- du système de fichiers) => il faut que le type de la partition soit en conformité logique avec le système de fichiers inscrit. Décrire comme de type "Microsoft Basic Data" une partition dont le système de fichiers inscrit sur les blocs est un jhfs+ d'Apple => introduit une "inconsistance formelle" qui proscrit la prise en charge du système de fichiers par le kernel.
Je ne sais pas si ces considérations t'éclairent un peu sur la problématique de recréation d'un descripteur de partition ?
