Salut
PDD.
En
épigone de mes trois prédécesseurs :
Locke 
,
r e m y et
Ruben ), je suis voué à enfoncer les portes qu'ils ont ouvertes avec la grisante sensation des espaces libres
Le répertoire graphiquement invisible :
var est ainsi nommé par abréviation de :
variable. Ce qui indique que les éléments qu'il contient sont des fichiers à contenu sujet à
variation requis par le fonctionnement du Système de l'OS (à la différence, par exemple, des éléments à contenu '
fixe', tels les fichiers structurels de la
Bibliothèque-Système ou encore des répertoires
/bin ou
/sbin contenant les programmes binaires UNIX.
En exemple de ces fichiers à contenu
variable : les
logs (journaux) du Système, les
db (database : base de données de caches), les
folders (références d'affichage graphique), les
vm (virtual machine : la
sleepimage ou cliché du Bureau actif à la mise-en-sommeil d'après l'option de veille standard, ainsi que les
swapfiles éventuels = extension de la RAM au disque). Tout cela fait pas mal de Go ensemble, c'est sûr...
...mais que se passerait-il en cas de suppression du répertoire
var? - Un plantage sans appel de l'OS, car cet emplacement est requis par de multiples processus du Système précisément pour y archiver et/ou consulter ces données à caractère
variable. Et le Système ne peut pas régénérer un répertoire
var supprimé, s'il faisait défaut, non plus que son arborescence en multiples sous-dossiers spécifiques, s'il était dévasté formellement de l'intérieur.
Le répertoire
var fait partie des 3 dossiers-Système à présenter une
anomalie logique remarquable depuis les origines d'
OSX : les 3 dossiers recelés dans le super-répertoire
/private (avec
tmp et
etc) --> celle d'avoir leur chemin d'accès
extrapolé hors du répertoire parent directement à l'espace-racine de l'OS ouvert à partir du point de montage / sous forme de
liens symboliques :
/⤻etc,
/⤻tmp et
⤻var. Cette
anomalie logique prend valeur de 'révélateur' : la nécessité pour toutes sortes de processus de pouvoir 'appeler directement' ces destinations depuis la racine.
Il me revient en mémoire l'affaire d'un billettiste de ce forum, qui avait cru bien faire en
ne supprimant
que le
lien symbolique : ⤻var, indûment démasqué, en le prenant pour une espèce d'
alias en souffrance dans l'espace-racine de l'OS --> le résultat ne s'était pas fait attendre : plantage du Mac au re-démarrage et obligation d'instruire le plaignant sur la manière, démarré sur le «
Recovery HD», de re-créer dans le «
Terminal» un
lien symbolique : ⤻var avec les droits corrects afin de pouvoir démarrer son OS. Et il n'avait même pas supprimé l'original (le dossier
var contenu dans le super-répertoire
/private). Ce qui permet néanmoins de conclure à la nécessité incontournable de l'existence de cette destination pour le fonctionnement de l'OS.
Il n'est pas impossible, intrinsèquement, de 'faire le ménage' à la
pince entomologique à l'intérieur de l'arborescence préservée de
/private/var en s'attaquant à son contenu de fichiers. J'avoue m'en être assidûment rendu coupable
. Oui : j'ai bidouillé ma
sleepimage en la remplaçant par un fichier verrouillé vide (ce qui me fait gagner de 8 à 16 Go) tout en choisissant le mode du
sommeil simple classique. Idem pour les
swapfiles. J'ai sévi régulièrement, tel un
Attila iconoclaste dans le dossier
com.apple.IconServices, lorsque «
Mavericks» était nanti d'un processus
IconAgent bogué qui générait
itérativement du cache-graphique sous forme d'une inflation de fichiers séparés. J'avoue : j'ai ravagé les
logs, j'ai désherbé le
cache, j'ai sournoisement investi le
Home_Folder de
root...
Pfuit! Tout cela n'est qu'une
fuite en aval vaine, voire dangereuse si on ne sait pas ce qu'on fait quand on le fait. Car sans arrêt les destinations de
var se ré-emplissent avec le fonctionnement du Système. La solution est
en amont, quand on se pose des problèmes de place : arrêter de gonfler son
Home_Folder d'utilisateur de fichiers graphiques qui auraient meilleure latitude de s'ébattre sur des supports externes ...
