Salut
tit_juju.
Voici comment j'interprète ton problème : tu n'arrives pas à faire remasquer par le
Finder les fichiers invisibles de ton Mac, parce que tu n'arrives pas, dans le fichier de préférences de ton compte : le
~/Library/Preferences/com.apple.finder.plist, à éditer pour la clé
<key>AppleShowAllFiles</key> (Apple_montrer_tous_fichiers) en charge de cette option, la valeur actuelle de la chaîne associée
<string>YES</string> à la valeur inverse -->
<string>NO</string>. Lorsque tu édites la valeur comprise dans la chaîne
<string></string> et que tu sauvegardes ton édition du fichier, après relance du
Finder, si tu inspectes derechef ton fichier de préférences, la valeur antérieure
YES a été récupérée par la chaîne -->
<string>YES</string> et, par suite, le
Finder persévère à afficher les fichiers invisibles.
L'édition des fichiers de préférences d'applications (et le
Finder en est une) pour un compte d'utilisateur donné peut s'opérer de 2 façons : soit en manuel (comme tu l'as tenté, et dans cette optique je te conseillerais te passer par l'excellent éditeur de fichiers-système : ☞
TextWrangler☜ plutôt que par «
Xcode») - mais l'intervention manuelle dans un fichier de préférences est toujours assez délicate, étant donné la syntaxe articulant clés et chaînes de ce type de fichiers ; soit par l'intermédiaire du programme
UNIX :
defaults, invoqué avec le verbe
write - ce qui est la méthode disons la plus orthodoxe pour éditer un fichier de préférences d'utilisateur.
Si une clé contient le "titre" d'un option de préférence déterminée (comme ici :
<key>AppleShowAllFiles</key>), une chaîne, elle, contient la valeur qui lui est associée dans le fichier de préférences. Valeur binaire : soit
positive, soit
négative, dont le point remarquable est qu'elle est susceptible d'une kyrielle de types d'énoncés que le Système de l'OS est capable d'honorer équitablement --> cela va des valeurs binaires opposées :
<key>TRUE</key> vs
<key>FALSE</key>, à :
<key>YES</key> vs
<key>NO</key> et à
<key>1</key> vs
<key>0</key>, ou même à :
</true> vs
</false>.
À supposer que l'utilisateur se soit "amusé" à invoquer le programme
defaults avec le verbe
write pour un fichier de préférences donné, et à lui faire éditer, pour une clé donnée (comme
<key>AppleShowAllFiles</key>) la valeur de la chaîne associée selon ces divers modes en
positif vs en
négatif, alors le résultat dans le fichier de préférences en question peut-être une superposition de variantes du type (copié d'après mon fichier
com.apple.finder.plist de «
Yosemite» après que je me sois amusé à "créer volontairement de la confusion") :
Bloc de code:
<key>AppleShowAllFiles</key>
<string>1</string>
<key>AppleShowAllFiles</key>
<string>FALSE</string>
<key>AppleShowAllfile</key>
<string>1</string>
<key>AppleShowAllfiles</key>
<string>1</string>
ce qui révèle qu'une confusion d'écriture certaine est susceptible d'intervenir dans un fichier de préférences, non seulement par itération d'écritures identiques (
<key>AppleShowAllfile</key> <string>1</string>), mais encore par contradiction d'écritures relevant d'options diverses de saisie de la valeur de la chaîne associée :
<string>1</string> vs
<string>FALSE</string>.
Il semble, dans ces conditions, que l'utilisation du programme
defaults soit incapable de remettre de l'ordre dans ce fourbi, et qu'une expurgation manuelle des binômes redondants, voire paradoxaux, s'impose comme la seule option pour simplifier les valeurs associées à un "titre" de préférence. À moins carrément de "benner" le fichier de préférences, afin qu'il soit recréé aux valeurs simples par défaut (ce qui fait perdre tous les réglages personnalisés).
---------------------
Les considérations qui précèdent soulèvent un problème : comment se fait-il qu'une pareille confusion d'écritures par itérations et/ou contradiction de valeurs soit possible dans un fichier de préférences d'application, dont on attendrait logiquement qu'il soit régi par un protocole d'
exclusion logique : soit
1 soit
0 (mais pas les 2 à la fois), et d'
unicité logique : un seul énoncé déterminant pour chaque option possible (et pas une itération) ? Cette confusion d'écritures par itérations paradoxales/redondantes était justement ignorée dans toutes les versions d'
OS X précédant «
Mavericks 10.9». Je me suis amusé, sous «
Lion 10.7.5», à éditer mon fichier
com.apple.finder.plist via
defaults en recourant alternativement, pour la clé
<key>AppleShowAllFiles</key> aux valeurs inverses :
positif v
négatif en jouant sur les différentes variantes de saisie possible :
<key>TRUE</key> vs
<key>FALSE</key>, à :
<key>YES</key> vs
<key>NO</key> et à
<key>1</key> vs
<key>0</key> --> il n'en résulte jamais une itération (ni redondante, ni paradoxale), mais toujours un remplacement exclusif de la saisie antérieure. Ce qui signe un beau "déterminisme logique".
Pourquoi, alors, cette unilatéralité logique se trouve-t-elle brouillée à partir de «
Mavericks 10.9» et de «
Yosemite 10.10» ? Parce qu'à partir de «
Mavericks 10.9», le fonctionnement du Système passe par un recours aux
caches généralisés, recours aux caches qui s'est trouvé étendu à la gestion des préférences d'applications. Avant «
Mavericks», lorsqu'on lançait une application (et cela valait aussi pour le
Finder qui se lançait automatiquement en ouverture de session), il y avait "consultation" directe du fichier de préférence d'utilisateur dédié et l'application s'ouvrait en prenant en compte les paramètres du fichier
.plist.
À partir de «
Mavericks», un service a été mis en place dénommé :
cfprefsd (
Core
Foundation
Preferences
Service
Daemon), qui est un processus tournant en toile de fond qui met en cache les fichiers de préférences d'applications. Ce service se décline en 2 versions : la version "
Daemon" à proprement parler (service-Système, possédé par
root) et la version "
Agent" à proprement parler (service-Utilisateur, possédé par l'
user). Je m'en tiendrai ici à la version "
Agent", la seule qui concerne les fichiers
.plist de compte utilisateur.
Donc notre
cfprefsd, au premier lancement d'une application, met en cache les paramètres de ton fichier
.plist d'utilisateur et, les fois suivantes, lorsqu'il y a lancement de la même application, celle-ci est proscrite de "consultation" directe du fichier
.plist dédié : elle doit nécessairement s'adresser au service de toile de fond
cfprefsd qui lui transmet en retour les paramètres de ses préférences d'utilisateur. Le problème étant que ces paramètres dépendent, non directement du fichier
.plist original, mais indirectement du cache qu'a créé
cfprefsd. Or un cache a toujours une inertie, parce que le service qui en assure la gestion ne se réfère que de loin en loin, suivant une périodicité qui lui est absolument propre, au fichier original pour éditer le cache en fonction des modifications éventuelles de ce fichier.
Dès lors que le service de toile de fond
cfprefsd gère à partir de «
Mavericks» les préférences
per_user d'applications selon le procédé de la mise-en-cache, alors surgit la possibilité que l'édition d'un fichier de préférences
.plist n'ait absolument aucun impact sur le comportement de l'application concernée, même après relance de celle-ci - ce, parce que l'application est obligée de consulter
cfprefsd pour la délivrance de ses paramètres de préférences, et que ce dernier ne les lui délivre que d'après le cache qu'il a constitué sans qu'aucune édition du fichier
.plist original n'ait d'impact immédiat sur ses paramtères.
Mais il y a bien plus : un certain nombre d'utilisateurs ont constaté (et l'on pourrait parler ici carrément de "
bogue") que
cfprefsd, outrepassant cette fonction consistant à "
différer" la prise-en-compte d'un changement de paramétrage du fichier
.plist original de par l'inertie du cache servant de service de préférences obligé pour l'application ; était susceptible d'
invalider toute possibilité de saisie d'une édition de paramètre du fichier
.plist par l'utilisateur. Que ce dernier opère en manuel, ou même qu'il passe par le truchement du programme
defaults. En effet, le fichier paraît bien dans un premier temps avoir été édité, mais à la relance de l'application correspondante, il s'avère que la valeur éditée de la chaîne pour une clé donnée a été restaurée à la valeur antérieure. Dans pareil cas, plus que d'un phénomène d'
inertie du cache, il s'agit d'un phénomène de
verrouillage du fichier
.plist par le cache.
[Pour rajouter à l'
imbroglio : en ce qui me concerne, je fais le constat diamétralement opposé qui m'avait servi de base de conjectures : je peux éditer mon fichier
.plist par toutes sortes d'itérations du binôme : clé / chaîne (itérations redondantes vs paradoxales), ce parce que le comportement de l'application lancée (ici le
Finder) dépend du cache géré par
cfprefsd et pas directement du fichier
.plist original --> au lieu de me retrouver avec un fichier "verrouillé" comme
tit_juju, j'hérite d'un fichier "raturable" en tous sens : possibilité exclue sous les versions d'
OS X antérieures à
10.9, avec lesquelles le fichier
.plist était directement déterminant du comportement de l'application et devait donc ne comporter que des paramètres univoques...]
--------------------
Tu n'as jamais précisé (me semble-t-il),
tit_juju, quel était ton OS et je m'avance donc, ici, à supposer qu'il s'agit soit de «
Mavericks 10.9», soit de «
Yosemite 10.10», parce que ton incapacité (telle que tu la décris) à éditer ton fichier
com.apple.finder.plist d'une manière qui "tienne" pour dicter le comportement du
Finder relativement à la clé :
<key>AppleShowAllFiles</key>, me paraît relever de l'effet de cache du service
cfprefsd, lequel n'existe que dans ces 2 OS récents.
Si je n'ai pas erré, alors voici le "court-circuit" qui a été proposé, et qui opère en 2 temps :
- a) Ouvre d'abord ton «
Terminal» et fais un copier-coller dans sa fenêtre de la commande :
Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 0 ; killall Finder
mais n'active surtout pas cette commande (ne presse pas sur la touche ↩︎ = "Entrée" du clavier). Contente-toi de la laisser
en instance. Garde ta fenêtre du «
Terminal» ouverte, bien à disposition, sur un côté de ton écran (le gauche par exemple).
- b) Dans le même dossier que celui du «
Terminal» (
Applications/Utilitaires), lance en parallèle du «
Terminal» le «
Moniteur d'activité». Dispose sa fenêtre ouverte de l'autre côté de ton écran (à droite par exemple). Arrange-toi (menu supérieur :
Présentation) pour sélectionner l'option : "
Toutes les opérations". Dans la fenêtre, tu peux cocher le menu : "
Processeur" (peu importe, en fait, ici). Dans la toute petite barre de sous-menus, clique tout à gauche sur le titre : "
Nom de l'opération" afin d'obtenir un listing dans l'ordre alphabétique croissant. Déroule les items et tu vas voir affichés 2
cfprefsd : ne sélectionne que la ligne de celui dont le "
Nom d'utilisateur" (tout à droite) mentionne, non pas
root (il s'agit-là du "
Daemon" en charge des préférences-Système), mais ton propre
nom d'utilisateur (il s'agit de l'
Agent qui gère tes préférences de compte).
--> Cela fait, va tout en haut à gauche de la fenêtre du «
Moniteur d'activité» au bouton marqué d'un croix :
x et presse-le : dans le panneau d'options qui se démasque, choisis "
Forcer à quitter" -->
attention ! tu as quelques secondes à peine pour agir, entre le moment où tu forces l'Agent cfprefsd à quitter et le moment où il va être recréé !
- c) comme la foudre
--> déplace ton pointeur pour cliquer la fenêtre du «
Terminal» et la ramener à l'avant-plan et presse dans la foulée la touche ↩︎ ("Entrée") du clavier pour activer la commande déjà saisie et en instance de passation :
Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 0 ; killall Finder
--> même si tes fichiers "cachés" sont toujours visibles, inspecte ton fichier de préférence :
com.apple.finder.plist --> est-ce que la valeur dans une chaîne
<string>0</string> est bien fixée sous une clé
<key>AppleShowAllFiles</key> ? Si oui, alors :
- d) dans le «
Moniteur d'activité», re-tue l'
Agent :
cfprefsd correspondant à ton
nom d'utilisateur et
re-démarre ton Mac dans la foulée...
☞ est-ce que tu es parvenu à "prendre de vitesse" le service de caches des préférences
cfprefsd ?
--------------------
