Salut
tenets
Comme
Moon 
te le signale > on ne peut pas
réparer le système de fichiers qui gère un volume sans
démonter ce volume au préalable. Comme cette opération est impossible aussi longtemps que l'OS de ce volume est démarré > il convient alors de démarrer sur un autre Système comme le
Recovery OS.
Mais il est possible de
vérifier ce même système de fichiers (sans que les erreurs qui peuvent être trouvées soient réparées). Pour cela > la commande la plus commode est :
Parce que l'utilitaire
diskutil est un «
wrapper » : un "enveloppeur de commandes", qui distribue les tâches à des sous-utilitaires spécialisés en fonction de ce qui lui est commandé. Ainsi, le verbe
verifyVolume à destination d'un volume au format
JHFS+ (comme celui de l'OS) > conduit
diskutil a appeler l'utilitaire spécialisé
fsck_hfs (
filesystem_check_hfs : utilitaire de vérification de système de fichiers au format
HFS) > avec en coulisses le choix des options qui vont bien (comme l'option -
l - "
live" - qui opère le gel momentané des opérations du volume monté le temps que
fsck_hfs vérifie les fichiers du système de fichiers).
Il est donc beaucoup plus confortable d'appeler
diskutil en lui faisant confiance pour employer
ad hoc tel sous-utilitaire spécialisé > que de bricoler à la main une série d'options pour l'utilitaire
fsck_hfs.
----------
Si tu tiens spécifiquement à employer l'utilitaire
fsck_hfs à destination du système de fichiers du volume monté de l'OS > je te suggère les 2 opérations suivantes :
- a) toujours passer d'abord une commande :
retournant le tableau des partitions avec les identifiants d'appareil (
device) > parce que
fsck_hfs demande exclusivement une mention de
device comme cible. Le
device du volume de l'OS est couramment
disk0s2 (disque
0 ou premier disque >
slice 2 ou 2è tranche logique) > mais il suffit qu'un système de stockage
CoreStorage soit greffé sur la partition en question pour que le système de fichiers-cible soit déporté sur un device virtuel de 2è ordre =
disk1 (le
dev_node du
Volume Logique du
CoreStorage) - ce qui oblige à modifier la mention du device-cible.
- b) toujours introduire l'option
-l (
live) pour forcer le gel provisoire (freeze) des opérations dans le volume > et par là suspendre l'activité du système de fichiers en vue de la lecture de ses fichiers. Cette demande d'opération
live implique l'emploi de
sudo.
=> pour un device-cible standard =
disk0s2 > une commande :
Bloc de code:
sudo fsck_hfs -l /dev/rdisk0s2
fera alors l'affaire (l'emploi de
r avant le
disk0s2 signifiant "
raw" : adresser le
device brut sans le filtre du cache). Par rapport à la confortable simplicité de la commande :
tu noteras le maniement ingrat de la commande
fsck_hfs : déjà orthographier correctement cet intitulé absurde est
a pain in the ass pénible > mais en plus il faut passer en
root par
sudo pour autoriser le virage au mode "
live" --> ce qui implique de saisir un mot-de-passe d'authentification > et encore il faut passer la commande
diskutil list préalable pour être sûr de l'identifiant de
device de la partition-cible. Pfuttt ! faux être maso...
