10.12 Sierra Problème de fichiers cachés

nonodevil

Membre confirmé
18 Mars 2010
35
1
50
Lyon
Bonjour,
J'ai installé un nouveau DD de 500Go sur mon MBP. J'avais un disque de 250 Go avant, rempli à hauteur de 185 GO.
J'ai transféré les sauvegardes Time Machine que j'avais, et je pense avoir fait une erreur, car j'ai transféré une fois une sauvegarde de novembre dernier, puis j'ai restauré celle que je voulais, à savoir celle de mars 2017.

Problème : Quand je regarde les infos sur mon HDD, cela me donne :
- capacité : 499,25 Go
- Disponible : 83,75 Go
- Utilisé : 415 Go

Et quand j'additionne les sous dossiers :
- Applications : 18 Go
- Système : 7,8 Go (Sierra)
- Bibliothèque : 6,7 Go
- Utilisateurs : 152 Go
J'arrive donc à 185 Go plus ou moins, mais je ne comprends pas comment je peux avoir 415 Go d'utilisés.

Y aurait il quelque part des fichiers cachés liés aux deux ajouts de sauvegarde Time Machine et que je n'arrive pas à effacer ?

Quand je passe Dr Cleaner Pro avec la recherche des fichiers en doublon, il me dit qu'il n'y a rien...

Bizarre.

Merci d'avance pour vos réponses.
 
Ce qui compte est ce qu'il y a effectivement sur l'espace du disque : avec l'Utilitaire de disque tu regardes simplement l'espace occupé/libre des différents volumes présents sur l'ordinateur.
Ou, dans Terminal, tu tapes la commandes :
Bloc de code:
df -h
et, si le résultat ne te paraît pas parlant, tu nous l'affiches.

Je suppose que tu as utilisé le module d'affichage du contenu du disque, complètement véreux et que Apple ne semble pas décidé à corriger (ou supprimer). Ça ne fait pas très sérieux, cela génère des dizaines de fils dans les forums.
Et cela ne m'incite guère à utiliser les services en ligne de iCloud : si le système évalue aussi mal ce qui est présent sur les volumes, je ne vois pas bien comment il pourrait travailler correctement avec le stockage en ligne.
 
Oui, je me suis aperçu qu'il y avait dans "invités" une grosse partie de fichiers non utilisés, je les ai virés. Avec ta commande, cela me donne ça :
Bloc de code:
Filesystem      Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s2   465Gi  244Gi  220Gi    53% 1663658 4293303621    0%   /
devfs          182Ki  182Ki    0Bi   100%     628          0  100%   /dev
map -hosts       0Bi    0Bi    0Bi   100%       0          0  100%   /net
map auto_home    0Bi    0Bi    0Bi   100%       0          0  100%   /home
J'ai donc gagné de la place, mais j'ai toujours 60 Go de trop. Je pense qu'il y a des trucs dans le dossier "partagés" mais je n'arrive pas à nettoyer.
 
C'est même un peu plus.
Le Finder te donne des informations en GB (giga-octets normalisés, c'est-à-dire où 1 GB = 10^9 octets) tandis que Terminal reste fidèle (comme moi...) aux GiB des origines (1 GiB = 2^30)
df t'indique 244 GiB utilisés, ce qui équivaut à 262 GB. Donc 77 GB de plus que ce que tu as comptabilisé.

Si tu veux avoir une meilleure idée de la répartition des charges, tu peux utiliser un petit outil fiable, OmniDiskSweeper (téléchargeable ici). Pour qu'il soit complet, il faut le lancer avec les droits d'administrateur.
Aussi, si tu l'as installé normalement (dans /Applications), tu tapes dans Terminal :
Bloc de code:
sudo "/Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper"
(le shell te demande ton mot de passe, que tu entres à l'aveugle (c'est normal) et que tu valides en appuyant sur la touche Enter).
Après analyse tu verras assez clairement l'occupation réelle du disque.
 
C'est même un peu plus.
Le Finder te donne des informations en GB (giga-octets normalisés, c'est-à-dire où 1 GB = 10^9 octets) tandis que Terminal reste fidèle (comme moi...) aux GiB des origines (1 GiB = 2^30)
df t'indique 244 GiB utilisés, ce qui équivaut à 262 GB. Donc 77 GB de plus que ce que tu as comptabilisé.

Si tu veux avoir une meilleure idée de la répartition des charges, tu peux utiliser un petit outil fiable, OmniDiskSweeper (téléchargeable ici). Pour qu'il soit complet, il faut le lancer avec les droits d'administrateur.
Aussi, si tu l'as installé normalement (dans /Applications), tu tapes dans Terminal :
Bloc de code:
sudo "/Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper"
(le shell te demande ton mot de passe, que tu entres à l'aveugle (c'est normal) et que tu valides en appuyant sur la touche Enter).
Après analyse tu verras assez clairement l'occupation réelle du disque.
Salut

Ou plus simplement ;):
sudo open -a omnidisksweeper
 
Et donc, avec ODS, on peut effacer les fichiers que l'on ne souhaite pas garder ?

Par exemple, puis-je virer tous les fichiers, ne garder que Système, Applications et Bibliothèque et ensuite refaire un transfert de ma sauvegarde Time Machine ?
 
Y aurait il quelque part des fichiers cachés liés aux deux ajouts de sauvegarde Time Machine et que je n'arrive pas à effacer ?
Passe par le menu Finder > Aller > Aller au dossier (Cmd+Maj+G) pour y taper /Volumes

= c'est là où on retrouve habituellement les restaurations maladroites de Macintosh HD.


Il faudra que tu te demandes comment "transférer" d'anciennes sauvegardes TM !
 
Que veux tu dire par là ?
Que tu as merdouillé deux fois, et que tu peux éviter la troisième. :D

Je te soupçonne d'avoir cliqué sur le bouton Restaurer dans l'interface de TM, au lieu de passer par Assistant de Migration ou Recovery.
 
Exact, mais à vrai dire, cela n'a pas vraiment fonctionné. J'ai re-transféré mes fichiers cet AM via l'assistant de migration, et là c'est bon. Merci à tous.
 
Je l'avais constaté il y a un moment et j'ai refait un test pour m'en assurer de nouveau, avec Sierra (mais la question est la même avec les versions précédentes).

La ligne que j'indique lance l'application pour le compte de root, puisqu'elle lance le binaire (le code exécutable) directement avec l'identifiant de root (c'est le rôle de sudo par défaut).

Ce qui n'est pas le cas de l'autre ligne. En effet, dans ce cas c'est open qui est lancée pour le compte de root. Et, apparemment, open ne transmet pas les identifiants avec lesquels on la lance.

Fais un petit test : tu crées deux fichiers :
Bloc de code:
sudo touch /usr/local/brol1.txt
sudo touch /usr/local/brol2.txt
Et tu essayes de les supprimer respectivement avec OmniDiskSweeper lancé d'une manière puis, après l'avoir quitté (command-Q) lancé de l'autre manière.
 
Et tu essayes de les supprimer respectivement avec OmniDiskSweeper lancé d'une manière puis, après l'avoir quitté (command-Q) lancé de l'autre manière.
C'est peut-être lié au fait que, pendant longtemps, il a été conseillé de ne rien supprimer directement à partir d'OmniDiskSweeper ? (on conseillait alors de quitter ODS avant de supprimer via le Terminal ou le Finder)
 
Je pencherais plutôt pour une simple question de gestion des autorisations de la part du système et des applications.

[mode=hypothétique]
Dans le premier cas, on lance donc ODS par son fichier binaire directement et, avec l'aide de sudo, l'application est lancée (la méthode est celle de la fourchette (fork)) avec root comme propriétaire.

Dans le second cas, c'est la commande open qui est lancée avec root comme propriétaire. Ensuite, open discute avec un autre lanceur d'application, celui de la session de l'utilisateur, et lui demande suivant le protocole ad hoc de lancer l'application référencée par la chaîne de caractère "OmniDiskSweeper". Le lanceur cherche dans le registre des applications celle qui a ce nom et lance la première qu'il trouve dans sa liste. Ce registre est celui qu'entretient le Finder chaque fois que l'on copie/supprime/modifie une application sur le Mac.
Apparemment, open ne transmet pas au lanceur ses propres identifiants (my name is root) donc le lanceur utilise les siens (je m'appelle brol).

Plus généralement, on peut constater ce fait avec toute application et c'est assez facile avec celles pour lesquelles on a changé le paramétrage par défaut pour le personnaliser.
En la lançant de la premièe manière on doit retrouver le paramétrage par défaut.
En la lançant de la seconde manière on doit retrouver le paramétrage de la session.

Il y a un certain temps (Leopard ?), il me semble que open se comportait différemment. Mais, pour d'évidentes questions de sécurité, on est revenu à un comportement plus logique.
[/mode]
 
Parfois les méthodes les plus simples apparaissent inopinément, quand on n'y pense plus vraiment.

Une manière simple de vérifier le compte utilisé pour lancer un processus est de regarder ses caractéristiques. Donc il suffit de vérifier quel est le compte de OmniDiskSweeper avec le moniteur d'activité
(ou ps auxwww | grep OmniDiskSweeper dans un shell).