Salut
DuddY
sais tu ce qui c'est passé?
Les
systèmes de fichiers ne sont
pas scrutables pour les utilisateurs que nous sommes --> il s'ensuit que leurs
erreurs ou
accidents ne sont
pas représentables non plus.
Un
système de fichiers (comme le
Apple_JHFS+) est un dispositif logiciel > inscrit sur les blocs de départ du conteneur logique d'une partition > et dont le rôle est de
définir un volume de fichiers montable à partir de la
série de blocs porteurs d'écritures de la partition. En somme : c'est un mécanisme logique qui
présente les
écritures brutes des blocs de la partition dans la
forme d'un répertoire de fichiers : le
volume.
Ce dispositif du
système de fichiers est une «
structure » logique : une
combinaison de fichiers qui coopèrent à la tâche de définir le volume > fichiers dont chacun est dédié à gérer une
tâche particulière. Ainsi, il y a le "
catalog file" principal : fichier du
catalogue B-tree recelant une arborescence logique permettant l'accès aux fichiers en mode lecture > édition > ajout > suppression.
Il arrive (sans que l'utilisateur puisse s'en représenter la raison) que des
erreurs s'introduisent dans un fichier du
système de fichiers : par exemple encore, une valeur numérique erronée sur l'arborescence logique du fichiers du catalogue --> ce qui "coupe" littéralement l'accès à toutes les dérivations logiques issues de cet embranchement et donc l'accès aux fichiers de données correspondants.
Dans ton cas > voici ce que je lis à l'engagement de la vérification du
système de fichiers :
Bloc de code:
Checking Journaled HFS Plus volume
Invalid record count
Catalog file entry not found for extent
The volume could not be verified completely
Je risque l'interprétation suivante :
- décompte invalide du nombre de fichiers attendus dans la structure du système de fichiers
- fichier du catalogue non trouvé pour la gestion de "extent"
--> il s'agit de l'«
extent_overflow_file » : le
fichier des segments en excès. En effet, lorsqu'il y a écriture d'un
fichier long aux blocs de la partition > il arrive que la longueur du fichier empêche qu'il soit écrit sur une série continue de blocs contigus > parce qu'à un moment donné se présentent des blocs (dans la série suivie numériquement) qui sont déjà écrits pour d'autres fichiers.
Dans ce cas-là > le processus d'écriture échappe les blocs écrits et va chercher les prochains blocs identifiés comme libres dans la série numérique des blocs --> l'écriture du fichier est alors "
segmentée". Pour que la lecture d'un fichier "d'un seul tenant" soit possible --> en pareil cas le fichier dédié aux «
segments en excès » enregistre les blocs excédentaires séparés de la série de blocs de début d'écriture du fichier comme relevant de l'écriture du même fichier.
En somme > il s'agit d'un
annuaire de blocs distants les rattachant à une série de blocs de départ comme constitutifs d'un seul fichier.
Dans le cas de ton
système de fichiers > il est dit carrément : le fichier des «
segments en excès » a
disparu de la stucture logique du
système de fichiers. Il ne s'agit pas d'une
erreur dans le cataloguage logique du fichier > il s'agit d'une
absence radicale. Il y a un "trou" dans la structure du
système de fichiers.
Il est bien évident que cette lacune est
irréparable par les utilitaires destinés aux utilisateurs comme
diskutil. La
cause de cette disparition ? - comme je l'ai indiqué d'entrée, les
systèmes de fichiers constituant un
inscrutable pour l'utilisateur --> ce qui "arrive à cet inscrutable" est lui-même
inscrutable.
Un logiciel puissant comme «
DiskWarrior» (par exemple) pourrait peut-être
recréer un
système de fichiers jumeau complet à partir d'un scan des blocs de la partition et de ce que fournit déjà la structure logique restée en place. Ce qui permettrait de reconstruire le volume montable sur la partition. Il faut y mettre le prix, évidemment. Et opérer à partir d'un OS démarré installé dans un autre volume.
