La
table de partition GUID du disque (=
disk2) est
sans erreurs.
Mais pas le
système de fichiers JHFS+ de la partition
disk2s2. Afin d'établir une comparaison > voici l'affichage qui devrait être obtenu en cas de système de fichiers valide :
Bloc de code:
Started file system repair on disk0s2 nomduvolume
Repairing file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
Trimming unused blocks
The volume nomduvolume appears to be OK
File system check exit code is 0
Updating boot support partitions for the volume as required
Finished file system repair on disk2s2 nomduvolume
Il manque donc toute la partie-clé :
Bloc de code:
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
Trimming unused blocks
qui consiste au passage en revue des fichiers du
système de fichiers JHFS+ : le fichier des
segments en excès > du
catalogue B-tree > les fichiers des
liens multiples > de la
hiérarchie du catalogue > des
attributs_étendus > de l'
allocation des blocs > des
informations du volume + l'élagage des blocs sans emploi.
C'est cet examen terme à terme qui fait défaut pour le système de fichiers de la partition
disk2s2 - ce, sans qu'aucun message n'interprète spécifiquement la raison de cet échappatoire. L'
accès en lecture aux fichiers du système de fichiers est-il impossible ? - rien ne le déclare (--> ce qui serait signalé par une mention :
input / output error). Ne serait-ce pas plutôt parce que le
1er des fichiers à examiner (= le «
extents overflow file » ou
fichier des segments en excès : suite de blocs ou segment, séparé de la série de départ, sur lesquels est écrite la continuation des écritures de longs fichiers) => serait impossible à vérifier ? Lorsque c'est le cas > l'opération de vérification s'arrête sans mot dire en échappant le reste des objets à vérifier.
J'aurais donc tendance à conjecturer que le système de fichiers est théoriquement
adressable (lisible) mais
corrompu dans ses fichiers, dont le 1er (le
fichier des segments en excès) > ce qui fait avorter tacitement l'opération.
----------
Un système de fichiers inscrit sur l'en-tête d'une partition définit l'alignement des blocs de la partition comme un espace de fichiers montable : un volume. Ce volume n'est pas monté automatiquement par le système de fichiers, lequel ne fait que définir les conditions d'existence logique du volume. C'est le service
diskarbitrationd (daemon : arbitrage de disque) qui procède à la
probation du système de fichiers d'une partition > et en cas de
validation > passe au
kernel (noyau) la tâche (
system_call) de monter le volume sur la partition ; en cas d'
invalidation > avorte toute passation de tâche de montage au
kernel.
Dans le cas ici présent > le système de fichiers ne
passe pas la probation du service
diskarbitrationd > donc le volume est échappé de montage par le
kernel. L'absence de désignation d'un
nom de volume dans le tableau retourné par
diskutil est toujours le signe d'un système de fichiers non reconnu valide.
La commande d'information sur la partition que j'avais demandée n'a pas été passée correctement. Ce n'est pas :
diskutil info disk 2s2 (avec un espace entre
disk et
2s2) > c'est la commande :
(à condition que l'identifiant du disque n'ait pas varié et soit toujours
disk2 - sinon modifier le n° du disque)
- tu n'as qu'à la passer, Michel, et poster le tableau retourné > pour voir si l'on apprend quelque chose de plus.
Toujours en vue d'aller à la pêche aux informations > passe la commande :
(si
disk2s2 est bien toujours l'identifiant d'appareil de la partition - sinon ajuster)
- et poste le retour. Comme cette commande envoie une requête spécifique au service diskarbitrationd > c'est pour le cas où la mention d'échec contiendrait une information sur le rejet de validation du système de fichiers.
Et tant qu'on est dans les requêtes de montage du volume (en vue d'apprendre quelque chose de la déclaration de leur échec) --> passe encore la commande :
Bloc de code:
mount -t hfs -o noexec,noowners,rdonly -v /dev/disk2s2 /tmp
(si l'identifiant de la partition est toujours
disk2s2 - sinon ajuster)
- cette commande établit une requête de montage du volume de la partition disk2s2 conforme au type HFS dans le répertoire des fichiers temporaires /tmp pris comme point de montage > avec les options : ne pas exécuter de binaires affectés au système de fichiers > échapper les propriétaires > monter en mode lecture seule > être verbeux => quel est le retour ? - un :
Bloc de code:
/dev/disk2s3 on /private/tmp (hfs, local, noexec, read-only, noowners)
(signe de montage) ou un message d'erreur et lequel alors ?
=> tu n'as qu'à poster tous ces retours pour voir s'il y a une information à glaner.
