Exercice de 'critique littéraire' oiseuse par macomaniac
@
bompi &
François.
J'ai suivi avec grand intérêt votre échange pointu et concis sur la question de la vérification/réparation du "disque_de_l'OS" grâce aux différents outils natifs sur Mac. Malgré l'hétérogénéité de mon style propre qui cultive le mode '
verbose' et risque bien de faire tache - je me sens incité à joindre ma voix au chapitre.
♤
Dans le premier article de l'auteur cité par
François (
Safe Boot or Disk Utility vs 'fsck' in OS X), je trouve que
Topher Kessler pose une excellente question : «
quelle est la différence entre les 3 méthodes?» (option 'réparer le disque' de l'«
Utilitaire de Disque» à partir du démarrage sur un disque indépendant de celui de l'OS / démarrage en mode '
Sans échec' avec ⇧ / démarrage en mode '
Utilisateur Unique' avec ⌘S et commande
fsck -fy)? Question d'emblée résolue par la déclaration synthétique : «
The quick answer is "absolutely nothing"» (la réponse brève est : "absolument rien") assortie de la justification analytique : les 3 procédés produisent au final
le même effet = la mise en œuvre du programme
fsck_hfs sur le
filesystem de l'OS (la différence étant que l'emploi de ce programme est ré-itérable
ad libitum en mode '
Utilisateur Unique' ou via l'«
Utilitaire de Disque» d'un disque de démarrage indépendant, alors que le mode '
Sans échec' ne le déclenche que de façon
unicitaire).
Il est évident, nonobstant sa clarté, que cet article comporte une
omission, qui est le 4è procédé disponible à partir du démarrage sur un disque indépendant de celui de l'OS («
Recovery HD» ou DVD d'install selon les OS, ou encore clone) : à savoir le recours à la commande
diskutil dans le «
Terminal» disponible sur le disque indépendant en question.
Omission qui embrouille légèrement le tableau, parce que, sur un disque autonome, la fonction : '
Réparer le disque' de l'«
Utilitaire de Disque ne cible pas le seul
filesystem de l'OS (en bref : son
Volume), mais s'adresse au
disque tout entier en impliquant de surcroît une vérification/réparation de la
Table de partition GUID. Ce qui correspond dans la commande
diskutil du «
Terminal» au verbe :
repairDisk, là où c'est le verbe spécifique :
repairVolume qui débouche
stricto sensu sur la mise-en-œuvre du programme
fsck_hfs sur le
filesystem du
Volume de l'OS.
Je pense que le scrupule de conscience de
François : «
je me suis embrouillé dans mes explications» provient du flou du terme '
Disque' dans l'article de
Topher Kessler qu'il avait en tête, ce parce que l'«
Utilitaire de Disque» évoqué par l'auteur sans confrontation à la commande
diskutil dans le «
Terminal» ne comporte que l'équivalent du verbe :
repairDisk (du disque entier) et ignore le verbe :
repairVolume ciblé sur le seul
filesystem de l'OS abstraction faite de la
Table de partition GUID.
Puis-je me permettre une petite glose en chemin? Quand
bompi déclare : «
Disk Utility (Utilitaire de Disque en français) est son équivalent en mode graphique [NB. à la commande diskutil dans le «Terminal»], avec un peu moins de fonctionnalités parce que la cible est un utilisateur moins expert» - la réduction de la fonctionnalité '
Réparer' dans l'«
Utilitaire de Disque» à celle de
repairDisk avec mise entre parenthèses de celle de
repairVolume le démontre. Mais j'aimerais ajouter que cet 'habillage graphique' qu'est l'«
Utilitaire de Disque» n'est pas qu'une simplification des fonctions de la commande
diskutil dans le «
Terminal», car c'est aussi l'intégration (elle aussi simplifiée) de fonctions de la commande
hdiutil, car l'«
Utilitaire de Disque» ne se borne pas à gérer des
Disques, mais gère aussi des
Images-Disques (
DiskImages) avec les fonctions :
créer,
graver etc. qui ressortent de
hdiutil. Ainsi, l'«
Utilitaire de Disque» est comme une 'trousse à outils' graphique à la fois plus complète (au plan synthétique) que chaque commande isolée du «
Terminal» (
diskutil et
hdiutil), mais en même temps moins complète dans ses options (au plan analytique) que ce qui est disponible pour chacune en ligne de commande.
♧
Dans le 2è article cité par
François (
How to check for and fix OS X boot drive errors), je trouve que
Topher Kessler n'a pas maintenu la clarté synthétique de son précédent article, en ce qu'il ne fait pas ressortir l'
identité d'effet induit par les diverses méthodes qu'il décrit - à savoir, la mise-en-œuvre du programme
fsck_hfs dans tous les cas. Le lecteur peut avoir l'impression que re-démarrer le Mac en mode '
Sans Échec', demander la '
Vérification du Disque' dans l'«
Utilitaire de Disque», lancer la commande spécifiée :
diskutil verifyVolume dans le «
Terminal» ou encore la commande :
fsck_hfs -f constituent des procédés 'équivalents' mais 'sans rapport les uns avec les autres', alors que dans tous les cas de figure c'est bien le programme
fsck_hfs qui est lancé.
Ce qui embrouille encore plus cet article, est que l'auteur se focalise sur la fonction
Verify (en mélangeant d'ailleurs la vérification du
Disque qui est l'option unique de l'«
Utilitaire de Disque» et la vérification du
Volume de l'OS qui est spécifiable dans le «
Terminal» pour la commande
diskutil et la commande
fsck_hfs), mais qu'il n'hésite pas à évoquer au passage le démarrage en mode
Sans Échec qui ne se contente pas de lancer une vérification, mais commande une
Réparation s'il y a lieu et conclut par le recours à la commande
fsck_hfs -fy dans le «
Terminal» de l'OS démarré à fin de
Réparation du
Volume de l'OS, ce sans signaler qu'il s'agit là de la
seule et unique façon d'activer une
Réparation du
filesystem de l'OS en mode '
live' (volume monté et démarré) - ni l'«
Utilitaire de Disque» (avec sa fonction :
repairDisk), ni la commande
diskutil repairVolume ne pouvant être honorés en mode '
live'.
♡
Un point curieux chez cet auteur est que la commande
diskutil (depuis le «
Terminal» d'un disque de démarrage indépendant de celui de l'OS) n'est jamais mise en relief dans sa fonction de
Réparation (ni d'ailleurs interrogée dans sa façon de procéder à cet effet sur le
filesystem de l'OS). Combien plus clair ce tableau de
bompi :
En fait :
a) je crois que fsck -fy et diskutil repairVolume sont équivalentes (voir c)) ; elles vérifient et réparent le(s) volume(s) indiqué(s) ;
b) fsck_hfs -l se contente de vérifier un volume de type général HFS+ (et seulement HFS+) mais ne le répare pas ;
c) en fait fsck (comme diskutil) est la commande mère, qui appelle, suivant la nature des volumes indiqués, les commandes filles : fsck_hfs, fsck_msdos etc.
Et effectivement un démarrage sans échec effectue la vérification/réparation du volume de démarrage entre autres actions (nettoyage des caches).
ce qui me conduit (sous l'effet d'inertie du mode
verbose ici engagé
) à une dernière glose. C'est sans aucun doute le programme UNIX basique
fsck-hfs qui se trouve mis en œuvre en tant qu'
effet terminal, quel que soit le procédé
causal initial : démarrage en mode
Sans Échec, «
Utilitaire de Disque» ou commande
diskutil à partir d'un disque de démarrage autonome, commande
fsck dans le «
Terminal» du mode
Utilisateur Unique, et donc évidemment commande '
live'
fsck_hfs -fy dans le «
Terminal» de l'OS démarré.
Par rapport à ce programme UNIX basique
fsck-hfs,
fsck et
diskutil sont des '
wrappers' : des 'enveloppes logicielles' capables d'invoquer des 'programmes élémentaires'. '
Wrappers' - si je m'autorise une élucubration conjecturale - de niveau hiérarchique différent. Le '
wrapper' :
fsck relevant d'une couche logicielle juste 'au-dessus' de celle du programme UNIX élémentaire :
fsck-hfs, par sa capacité à invoquer préalablement l'autre programme UNIX élémentaire :
getfsent apte à lire le descritif d'entrée d'un
filesystem afin de retourner son identité - ce qui doit permettre au '
wrapper' :
fsck de 'savoir' quel programme UNIX élémentaire mettre en œuvre (
fsck_hfs vs
fsck_msdos) pour vérifier/réparer le système de fichiers cible.
Il m'apparaît alors que
diskutil est un '
wrapper' relevant d'une couche logicielle encore plus 'élevée', qui ressemble à une véritable 'trousse à outils' pleine de 'poches utilitaires', si je généralise à partir de la conjecture spéciale suivante : quand on recourt à la fonctionnalité
repairVolume, je me figure que
diskutil doit identifier le format du
filesystem cible avant de 'choisir' par exemple le programme
fsck_hfs pour vérifier/réparer, donc lancer un programme comme
getfsent pour retourner l'identité du
filesystem. Est-il vraisemblable que les ingénieurs de
diskutil, pour équiper la 'poche' :
repairVolume de cette 'trousse à outils', aient fabriqué un programme ad-hoc absolument spécial pour ce faire? Si je me fie à la puissante déclaration du grand scolastique nominaliste
Guillaume d'Occam (un anglo-saxon concentrant la tournure d'esprit de cette culture) : «
Il ne faut pas indûment multiplier les «Êtres-de-Discours» - je conjecture que les ingénieurs de
diskutil, par
économie pragmatique, ont dû se contenter de 'remplir' la 'poche' :
repairVolume de
diskutil par un simple
pointeur au '
wrapper' d'ordre plus élémentaire :
fsck déjà programmé pour lancer les outils basiques
getfsent (pour identifier le format du
filesystem) de manière à choisir
fsck_hfs (pour le volume d'OSX). Je conjecture un dispositif '
pyramidal' en quelque sorte, obéissant à un principe d'
économie des moyens destiné à restreindre au maximum la redondance des «
Êtres de Discours»
[j'entends d'aucuns dire à macomaniac qu'il gagnerait à en 'prendre de la graine' au lieu d'abonder dans le style 'verbose' - n'était le principe de 'parler pour ne rien dire' qui conduit icelui à multipier les mots sans créer d'«entités»... ].
♢
