Impossible d'afficher les fichiers/dossiers cachés

lesailes

Membre enregistré
10 Janvier 2014
3
0
Salut à tous ;)

J'ai installé un ssd (clean install maverick) dans mon macbook pro 2009,

Le gain est vraiment impressionnant !

Mais j'ai un petit problème,
avec ma session principal il est impossible d'afficher les dossiers/fichiers cachés, que ce soit avec la commande dans le terminal ou Onyx ça ne fonctionne pas,
mais si j'utilise la commande dans le terminal d'une session invité ou d'un nouvel utilisateur ça fonctionne.

Ce n'est pas très grave mais je suis obligé de changer de session lorsque j'ai besoin d'avoir acces aux dossiers/fichiers cachés,

Avez-vous déja rencontré e probleme ? Avez-vous une solution ?

Merci d'avance pour votre aide :up:
 
Salut lesailes.

La mésaventure que tu évoques m'intrigue plus que je ne saurais dire.

  • D'abord parce qu'elle est neuve pour moi. Directement : je n'en ai jamais fait personnellement l'expérience. Indirectement : je ne l'ai jamais entendue évoquer.

  • Mais encore plus parce que cette nouveauté contredit les attentes de mon bon-sens :

    • en règle générale, à ce qu'il me paraît, l'impossibilité de commander une opération tient à des permissions insuffisantes : ainsi, d'un administrateur qui veut activer le binaire:'purge' en l'absence de droits 'root', ou d'un utilisateur standard qui veut supprimer des fichiers-système en l'absence de droits d'administration => il faut donc élever le niveau de permissions de départ pour réussir ;

    • or, dans le cas que tu évoques, il semblerait, au contraire, que 'qui peut le moins peut le plus' et que 'qui peut le plus peut le moins' : au sens où l'utilisateur-admin aborigène = le '501' ne peut pas passer avec succès la commande rendant les fichiers cachés visibles de son Finder, et inversement qu'un utilisateur standard, ou même un simple invité, par contre, est, lui, capable de commander avec succès ce dévoilement pour son Finder => il s'avère que des permissions abaissées réussissent.

    ♤

Je vais donc me borner, ici, à 'amorcer' au sujet du cas évoqué les interventions que de plus sagaces ne manqueront pas de faire (ton serviteur étant à ses heures un spécialiste de l'art de 'booter_en_touche', càd. d'amorcer le 'boot_de_l'autre' :D).

  1. Tout d'abord, j'ai constaté depuis mon passage à «Mavericks» un phénomène curieux : la commande classique de révélation des fichiers cachés dans le «Terminal» est devenue sensible à la CASSE_HAUTE. Auparavant, en effet, il convenait d'écrire :

    Bloc de code:
    defaults write com.apple.[COLOR="Red"]F[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    (avec toutes les variantes possibles de l'option affirmative à la place de 'YES' : 1, -bool TRUE, -boolean true etc.) et la commande passait en révélant au Finder les fichiers cachés. Maintenant, dans l'environnement de «Mavericks», il faut impérativement écrire en CASSE_BASSE :

    Bloc de code:
    defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    (peu importe la variante de rédaction de l'option affirmative) pour que la commande passe. Curieusement, il est à noter par contre que la commande supplémentaire de relance du Finder (killall Finder) doit être impérativement rédigée en CASSE_HAUTE, l'énoncé en CASSE_BASSE : killall finder ne passant pas.

    ✼
  2. Ensuite, je constate que, dans une fenêtre 'bash' du «Terminal» dont le 'prompt' est automatiquement appendu à mon nom d'utilisateur-admin 501 (qu'on supposera : ~ macomaniac$ puisque je suis dans la session d'icelui), la commande en CASSE_BASSE :

    Bloc de code:
    ~ macomaniac$ defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    passe toujours en révélant les fichiers cachés (de même que la contre-commande, où 'YES' - ou tout autre équivalent - est remplacé par 'NO' - ou ses équivalents : 0, -bool FALSE, -boolean false etc.).

    ❈

  3. Par contre, à supposer que je veuille élever mes permissions en empruntant les droits de 'root' sous la forme que j'appellerais 'impersonnelle' de l'invocation sudo ainsi :

    Bloc de code:
    ~ macomaniac$ [COLOR="Red"]sudo[/COLOR] defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    alors, après renseignement du password admin permettant cette promotion, il y a toujours échec sans appel de la commande qui n'opère rien.

    ❆

  4. La seule invocation de droits 'root' pertinente est, au contraire, l'invocation préalable :

    Bloc de code:
    sudo -su macomaniac

    donnant lieu après password à un 'prompt' du type :

    Bloc de code:
    bash-3.2$

    Alors, la commande en CASSE_BASSE :

    Bloc de code:
    bash-3.2$ defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    passe sans problème en révélant les fichiers cachés.

    ♧

Je pense donc, lesailes, dans l'attente d'intervenants plus avisés que ton serviteur, que tu pourrais essayer successivement, dans ta session-admin '501' dont je supposerais que l'identifiant d'utilisateur est : lesailes (tu remplaces par ton nom d'utilisateur abrégé en minuscules) les commandes suivantes dont la ligne complète, prompt inclus, apparaîtra ainsi :

  • Bloc de code:
    ~ lesailes$ defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    en CASSE_BASSE pour l'invocation de 'com.apple.finder' afin de voir s'il y a révélation des fichiers cachés.

  • Et, en cas d'échec, la commande préalable :

    Bloc de code:
    sudo -su lesailes

    avec renseignement du password admin pour obtenir un 'prompt' du type : bash-3.2$ avant de re-passer la commande qui apparaîtra, 'prompt' inclus, ainsi :

    Bloc de code:
    bash-3.2$ defaults write com.apple.[COLOR="Red"]f[/COLOR]inder AppleShowAllFiles YES ; killall Finder

    pour vérifier si les fichiers cachés sont révélés à ton Finder


    ☞ c'est tout ce qui me vient à l'esprit, ce matin.

    ♡
 
Dernière édition par un modérateur:
Salut macomaniac,

Merci beaucoup pour ton retour,

J'ai suivi tous tes conseils mais malheureusement sans succès ;(

Pour le coup je suis totalement perdu...
 
Pour le coup je suis totalement perdu...

... et moi tout autant.

Le problème que tu évoques (impossibilité d'afficher les items cachés via le «Terminal» autant que via «Onyx» exclusivement dans ta session d'utilisateur principale) évoque immanquablement ce que pascalformac (l'«Homérique» :coucou:) appellerait : un compte d'utilisateur bancal ; néanmoins tu dis avoir effectué une Clean Install de «Mavericks», opération censée justement avoir installé sur ton Disque un système de fichiers 'droit dans ses bottes', y compris dans les paramètres du compte d'utilisateur-admin principal (le 501).

Ce qui laisse envisager paradoxalement la survenue d'une 'possibilité de l'impossible' : une 'Clean Install' pas si 'propre' que son nom l'énonce [évidemment si tu as, ultérieurement à cette 'Clean Install', utilisé l'«Assistant de migration», par exemple, pour récupérer les données de compte utilisateur-admin principal de ton OS antérieur sauvegardées sur un Disque Externe - ton ancien Disque Dur Interne, admettons ; alors le paradoxe n'en serait plus un puisque ta 'Clean Install' aurait pu être gauchie par la récupération d'un compte d'utilisateur tributaire des 'errances' du passé ].

Comme le problème se trouve cantonné aux paramètres de ton répertoire d'utilisateur principal, et n'affecte pas l'OS entier, tu pourrais envisager de puiser dans la panoplie classique des outils de réparation employables dans ce cas de figure. Pour ce faire, re-démarre la touche 'alt' tenue pressée pour accéder à l'écran de choix du disque de démarrage et choisis le disque intitulé : 'Récupération 10.9.1' (dit 'Recovery HD') pour ce faire [il s'agit du volume d'une partition invisible, dédié aux opérations de récupération du volume principal, qui s'installe automatiquement sur le Disque interne depuis l'OS «Lion 10.7»].


♤


Tu accèdes ainsi à l'espace graphique du Bureau simplifié de ce volume. Tu peux successivement utiliser 2 outils :

  1. Le «Terminal» (en allant à la barre de menus supérieure de l'écran, menu : Utilitaires, sous-menu : «Terminal»). Dans la fenêtre_bash qui s'affiche, tu tape directement après le 'prompt' du type bash-3.2$ :

    Bloc de code:
    resetpassword

    (= 'restaurer_mot-de-passe' en Anglais en un seul mot) et ↩︎ (retour-chariot : presser la touche 'Entrée' = 'Retour' du clavier pour activer la commande). Cette commande déclenche l'affichage à l'écran d'une interface graphique (GUI) dans laquelle tu négliges radicalement le menu principal (supérieur) proposant de ré-initialiser le mot-de-passe du compte d'utilisateur de ton choix. Tu vas, au contraire, au menu subalterne dédié à la ré-initialisation des autorisations. Dans l'espace de ce menu, tu renseignes :

    • à : Sélectionner le volume contenant le compte utilisateur ☞ ton OS «Mavericks 10.9» ;

    • à : Sélectionner le compte utilisateur ☞ ton compte d'utilisateur-admin principal 'desailes' (supposons que c'est son nom) ;

    • à : Ré-initialiser les autorisations et les listes ACL du répertoire de départ ☞ tu presses résolument le bouton : Réinitialiser [les 'listes ACL', ou 'listes d'Autorisations de Contrôle d'Accès', archivent tous les droits d'usage spéciaux, concernant tel ou tel utilisateur et relatifs à tel ou tel domaine d'accès : fichier, exécutable etc., qui ont éventuellement été entés en supplément des droits basiques (dits : POSIX) instaurés par le Système à l'installation].


    -------------------------------------------------------------------------------------------------------------------------------------


  2. Le «Terminal» quitté (comme n'importe quelle application dans n'importe quelle session d'utilisateur), aller dans la fenêtre d'accueil offrant diverses fonctionnalités de récupération à l'«Utilitaire de Disque» et dans sa GUI, une fois sélectionné le Volume supportant l'OS «Mavericks» = ligne inférieure (et pas le Disque du device global = ligne supérieure), utiliser successivement (par acquis de conscience) les menus :

    • Réparer le disque (en bas à droite) ;

    • Réparer les permissions du disque (en bas à gauche).

♡


Une fois ces opérations complétées, re-démarre normalement et vérifie dans le «Terminal» de ta session d'utilisateur-admin principal si la commande :

Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 1 ; killall Finder

s'exécute avec succès.

♢
 
Dernière édition par un modérateur:
Ce post m'intéresse davantage par son "mécanisme" que par le point précis qu'il traite, et qui est gênant, j'en conviens.

Ce que j'appelle "mécanisme" est le constat qu'avec Mavericks et des données antérieures à Mavericks, on peut rencontrer ou on rencontre quelques problèmes. Par contre, si l'on créée des données avec un nouveau compte créé sous Mavericks ce problème n'existe pas.
Ainsi, après avoir installé Mavericks en Clean Install sur un disque système, rendu "vierge", à partir d'un clé USB, j'ai récupéré les données à partir d'une sauvegarde (clone). Depuis j'ai des soucis avec Mail, et la gestion des règles qui ne fonctionne pas pour ce qui est "nouveau", ou, plus précisément, qui n'enregistre pas les modifications ni les créations. Par contre, si je fais de telles opérations à partir d'un compte de base vierge de tout message ancien, ça fonctionne.

Tout se passe comme si Mavericks ne savait pas exploiter ou ignorait certains éléments antérieurs à son installation. Je trouve donc une certaine analogie entre les constatations de lesailes et les miennes.
 
... et moi tout autant.

Le problème que tu évoques (impossibilité d'afficher les items cachés via le «Terminal» autant que via «Onyx» exclusivement dans ta session d'utilisateur principale) évoque immanquablement ce que pascalformac (l'«Homérique» :coucou:) appellerait : un compte d'utilisateur bancal ; néanmoins tu dis avoir effectué une Clean Install de «Mavericks», opération censée justement avoir installé sur ton Disque un système de fichiers 'droit dans ses bottes', y compris dans les paramètres du compte d'utilisateur-admin principal (le 501).

Ce qui laisse envisager paradoxalement la survenue d'une 'possibilité de l'impossible' : une 'Clean Install' pas si 'propre' que son nom l'énonce [évidemment si tu as, ultérieurement à cette 'Clean Install', utilisé l'«Assistant de migration», par exemple, pour récupérer les données de compte utilisateur-admin principal de ton OS antérieur sauvegardées sur un Disque Externe - ton ancien Disque Dur Interne, admettons ; alors le paradoxe n'en serait plus un puisque ta 'Clean Install' aurait pu être gauchie par la récupération d'un compte d'utilisateur tributaire des 'errances' du passé ].

Comme le problème se trouve cantonné aux paramètres de ton répertoire d'utilisateur principal, et n'affecte pas l'OS entier, tu pourrais envisager de puiser dans la panoplie classique des outils de réparation employables dans ce cas de figure. Pour ce faire, re-démarre la touche 'alt' tenue pressée pour accéder à l'écran de choix du disque de démarrage et choisis le disque intitulé : 'Récupération 10.9.1' (dit 'Recovery HD') pour ce faire [il s'agit du volume d'une partition invisible, dédié aux opérations de récupération du volume principal, qui s'installe automatiquement sur le Disque interne depuis l'OS «Lion 10.7»].


♤


Tu accèdes ainsi à l'espace graphique du Bureau simplifié de ce volume. Tu peux successivement utiliser 2 outils :

  1. Le «Terminal» (en allant à la barre de menus supérieure de l'écran, menu : Utilitaires, sous-menu : «Terminal»). Dans la fenêtre_bash qui s'affiche, tu tape directement après le 'prompt' du type bash-3.2$ :

    Bloc de code:
    resetpassword

    (= 'restaurer_mot-de-passe' en Anglais en un seul mot) et ↩︎ (retour-chariot : presser la touche 'Entrée' = 'Retour' du clavier pour activer la commande). Cette commande déclenche l'affichage à l'écran d'une interface graphique (GUI) dans laquelle tu négliges radicalement le menu principal (supérieur) proposant de ré-initialiser le mot-de-passe du compte d'utilisateur de ton choix. Tu vas, au contraire, au menu subalterne dédié à la ré-initialisation des autorisations. Dans l'espace de ce menu, tu renseignes :

    • à : Sélectionner le volume contenant le compte utilisateur ☞ ton OS «Mavericks 10.9» ;

    • à : Sélectionner le compte utilisateur ☞ ton compte d'utilisateur-admin principal 'desailes' (supposons que c'est son nom) ;

    • à : Ré-initialiser les autorisations et les listes ACL du répertoire de départ ☞ tu presses résolument le bouton : Réinitialiser [les 'listes ACL', ou 'listes d'Autorisations de Contrôle d'Accès', archivent tous les droits d'usage spéciaux, concernant tel ou tel utilisateur et relatifs à tel ou tel domaine d'accès : fichier, exécutable etc., qui ont éventuellement été entés en supplément des droits basiques (dits : POSIX) instaurés par le Système à l'installation].


    -------------------------------------------------------------------------------------------------------------------------------------


  2. Le «Terminal» quitté (comme n'importe quelle application dans n'importe quelle session d'utilisateur), aller dans la fenêtre d'accueil offrant diverses fonctionnalités de récupération à l'«Utilitaire de Disque» et dans sa GUI, une fois sélectionné le Volume supportant l'OS «Mavericks» = ligne inférieure (et pas le Disque du device global = ligne supérieure), utiliser successivement (par acquis de conscience) les menus :

    • Réparer le disque (en bas à droite) ;

    • Réparer les permissions du disque (en bas à gauche).

♡


Une fois ces opérations complétées, re-démarre normalement et vérifie dans le «Terminal» de ta session d'utilisateur-admin principal si la commande :

Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 1 ; killall Finder

s'exécute avec succès.

♢

Oui ma clean install n'est peut-etre pas si clean que ca finalement car j'ai effectivement recuperer les donées utilisateur que j'ai laissé sur le hdd (OS sur SSD et User dans HDD)

J'ai essayé les manipulations que tu m'as proposé, toujours sans succés,

Par contre avec pathfinder ca fonctionne, je peux via les options pathfinder afficher les dossiers cachés...
 
Oui ma clean install n'est peut-etre pas si clean que ca finalement car j'ai effectivement recuperer les donées utilisateur que j'ai laissé sur le hdd (OS sur SSD et User dans HDD)

☝︎ :D

- et voilà pourquoi votre fille est muette...


«Mavericks» se retrouve donc «innocenté» (selon l'expression de François[MacG] dans un autre fil). À qui macomaniac (légèrement entamé par une séance de jeu de billes un travail d'écriture dans une autre fil également) a bien envie de renvoyer la bille boule balle par un appel du pied téléphoné qu'on ne pourra pas assimler pour le coup à un boot_en_touche. Le susnommé François se délectant des sournoises questions de permissions qui se font des nœuds quand un utilisateur se prend les pieds en marchant d'un soulier sur les lacets de l'autre... :D.

Car ça crève les yeux maintenant (grâce à un supplément d'informations qui faisaient défaut au départ - en quoi macomaniac eût dû comme l'aguerri Pascal[formac] demander un état des lieux préalable avant expertise) qu'il y a problème d'autorisations pour l'utilisateur-admin 501 référencé par un compte dans l'OS du SSD, mais dont le répertoire d'utilisateur réside sur un autre disque : l'ancien DDI principal qui a manifestement été viré à la place du Super-Drive interne, en cédant son emplacement au SSD (à moins que le SSD ne soit banalement venu remplacer le Super-Drive interne, ce qui est moins pratiqué).

⤻ ⚽︎ ⤏ FrançoisMacG
 
J'ai plutôt l'impression que tu me refiles la patate chaude… :)


PathFinder opère, tandis que Terminal et Finder rechignent : ça ne m'évoque donc pas un problème de permissions, même si le souci se cantonne à une seule session "récupérée",
mais plutôt un problème de plist, cache, application support, ou …

Je commencerais par les plist de finder, desktop et terminal,
mais sans savoir où et quoi chercher. :nailbiting:
 
Une solution vient d'être proposée par macfixit :

la commande defaults est sous la dépendance du processus cfprefsd,
et forcer à quitter ce processus dans l'Utilisateur avec Moniteur d'activité permet dans certains cas de valider la commande defaults

= How to tackle defaults not sticking in Mavericks | MacFixIt - CNET Reviews


Et comme Onyx n'est que l'habillage graphique de la commande du Terminal, il est possible que cela fonctionne pour lesailes.
 
J'ai plutôt l'impression que tu me refiles la patate chaude… :)

En bon renvoyeur de patate, François (sous l'inspiration de Topher Kessler dont le crâne rasé, le faciès hilare et la barbe en éventail évoquent immanquablement le sage_farceur Chinois) refile une racine de mandragore - dont chacun sait qu'elle est bifide, autant dire fourchue :D.


✍


  1. Dans la première branche de son argumentaire, Kessler relève une différence de fonctionnement de «Mavericks» avec les versions précédentes d'OSX :


    • Avant, quelqu'un voulant customiser les préférences de fonctionnement d'une application n'avait qu'à aller au fichier .plist correspondant (dans ~/Library/Preferences), à l'ouvrir avec un éditeur de texte comme «TextWrangler», voire avec un éditeur de texte du «Terminal» comme vim, à modifier la valeur incise d'une <key></key> et à sauvegarder la modification. Au relancement de l'application, le Système lisait directement le fichier écrit au Disque et l'édition prenait effet immédiat.

    • Avec «Mavericks», le Système procède par mise-en-cache des fichiers de préférences et lecture directe non des instructions du .plist du Disque, mais de celles du cache du fichier. La conséquence étant qu'une édition textuelle du .plist ne prend pas effet au relancement de l'application, puisque le paramétrage découle de la lecture du cache préalable, non modifié, du fichier .plist. Kessler constate donc à la fois un décalage temporel entre le fichier et son cache, le cache étant en retard sur le fichier, et un primat du cache sur le fichier. Par conséquent, le fonctionnement-système de «Mavericks» pour ce qui est de la prise en compte des préférences privilégierait l'inertie_ cache sur la mise-à-jour_fichier.

    • Afin de circonvenir cette perfidie de «Mavericks», la première rouerie décrite par Kessler consiste, préalablement au re-lancement de l'application, à invoquer le binaire /usr/bin/defaults par une commande defaults read dans le «Terminal» prenant le .plist édité pour objet, ce qui a pour effet normal de mettre-en-cache le fichier. Par suite, au relancement de l'application, le Système lirait les instructions d'un cache synchronisé avec l'édition du fichier.


      &#9758; en résumé de la manœuvre, l'invocation de defaults aurait un effet de synchronisation : cache / fichier, permettant de circonvenir le fonctionnement 'à inertie_cache' de «Mavericks».


    &#9998;

  2. Mais comme toute barbe en éventail a tendance à fourcher, c'est-à-dire à diverger en mode bifide (signe affiché d'un tempérament perfide, forcément), le nommé Kessler ne s'en tient pas là, mais dans une 2è branche d'argumentaire évoque la capacité de «Mavericks» à outrepasser ('override') la procédure de synchronisation forcée précédente, et le moyen de 'sur-circonvenir' cet outrepassement.

    • En effet, nous dit-il, un 'malin_génie' dénommé le 'cfprefsd' (ou 'Daemon' des 'CF_Préférences'), dont on sait qu'il appartient à l'espèce des 'derviches' qui 'tournent' constamment en toile de fond des opérations-système avant même le lancement de la session de l'utilisateur, a (peut-être pas en régle générale, mais du moins en occurrence aléatoire) la capacité, aussi longtemps qu'il tourne, de dénier la mise-en-cache par l'invocation de 'defaults' du fichier édité, et par conséquent de faire lire par le Système le cache antérieur préservé. Quand il n'opère pas carrément (si je lis bien ses 'bifidendentations' - hapax dédié au non moins perfide bompi :D) une ré-écriture d'après le cache antérieur conservé de l'édition du .plist, c'est-à-dire une rature de sa littérature, soit une 'allitérature' (par quel nouvel hapax j'entends une 'allitération' d'écriture du cache au fichier). En quoi ce perfide daemon veille, tel un Cerbère, à l'inertie du Système, par un rattrapage à rebours du cache par le fichier.

    • À roué, bi_roué s'affiche Kessler (expert en pirouette) : il suffit, après édition du fichier .plist par un éditeur de texte mais avant toute invocation de 'defaults' à fin de mise-en-cache du fichier, de tuer provoisoirement le processus tournoyant du daemon : 'cfprefsd', qui ne pourra donc pas s'opposer à la mise-en-cache du fichier édité grâce à la commande defaults read. Et ainsi, une fois relancé, le daemon : 'cfprefsd' qui veille jalousement sur la vertu du cache aux dépends du fichier aura été sur-circonvenu par la synchronisation bien établie du cache avec le fichier qui s'est opérée en son absence. CQFD.

&#10000;

&#9758; j'ai pris grand plaisir à scruter la mandragore lire le perfide Kessler grâce au retour de patate aux bons offices de François. Il semble paradoxalement que «Mavericks», afin de faire gagner du temps aux opérations d'applications (ce qui est la fonction du primat du cache sur le fichier écrit au Disque), a implémenté un mécanisme d'inertie temporelle résistant à l'aggiornamento : la non prise en compte immédiate, voire radicale, d'écritures éditrices des fichiers .plist qui se trouvent différées, voire raturées, par l'hégémonie du cache sur le fichier.

&#9996;&#65038;
 
D'après ce qui nous a été décrit là : 10.9: Preferences are cached - Mac OS X Hints

la commande defaults est la seule qui sache habituellement court-circuiter les caches affectés par Mavericks aux fichiers plist,
et le passage par un éditeur de texte (comme TextWrangler) ou de plist (comme PlistEditor ou XCode) ne donne de résultat immédiat qu'en relançant la session ou redémarrant le Mac.


L'article laisse en suspens le rythme de renouvellement des caches des plist : je n'ai pas encore lu d'information plus précise,
mais ta curiosité invétérée t'amènera peut-être à tester ton système, et ta faconde inépuisable à nous en donner les résultats. ;)
 
Concrètement, comment procède-t-on pour afficher et masquer les fichiers et dossiers invisibles avec Mavericks ?

Avant une commande Terminal ou l’aide d’un logiciel comme TinkerTool, Hidden Files, Onyx, etc. le permettait facilement, mais ça ne marche plus.

Configuration :
10.9.2 sur SSD interne et dossiers Utilisateurs sur un volume externe.
 
Salut Joël Pierre

Dans le «Terminal», la commande :

Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 1 ; killall Finder

et &#8617;&#65038; (presser la touche 'Entrée' pour activer la commande) permet l'affichage des fichiers cachés normalement au Finder. Inversement :

Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 0 ; killall Finder

et &#8617;&#65038; rétablit le masquage par défaut pour le Finder.

&#9758; je viens de tester : les 2 fonctionnent sans problème sous «Mavericks 10.9.2».

&#10043;​

Sinon, le plus commode est le recours à Onyx 2.8.3. Une fois l'application lancée, aller à : Paramètres/Finder/Options diverses/Afficher les dossiers et fichiers cachés &#9758; cocher la case et après relance du Finder les items invisibles sont révélés.

&#9758; je viens de tester encore : ça marche sans problème sous «Mavericks 10.9.2».


&#10057;

Si tu rencontres un problème, cela tiendrait-il à ta délocalisation du répertoire Utilisateurs sur un autre volume que celui où est installé l'OS?
 
Dernière édition par un modérateur:
Salut Joël PierreSi tu rencontres un problème, cela tiendrait-il à ta délocalisation du répertoire Utilisateurs sur un autre volume que celui où est installé l'OS?

La commande Terminal ne fonctionne pas (hormis que le Finder est relancé).

Avant que je ne délocalise le dossier Utilisateurs la commande Terminal et les utilitaires fonctionnaient. Depuis, plus du tout.

Onyx permet bien de rendre visible ou invisible un répertoire déterminé mais c’est bien lourd et terriblement lent. Avec le Widget Hidden Files, je passais d’un état à l’autre d’un clic.

La case qui permet de rendre visible les fichiers et dossiers se décoche toute seule dans TinkerTool !

tinkertool.PNG