Sujet unique Si le stockage « Système » prend trop de place

[Blue@512]

Salut Blue

La vérification du système de fichiers me paraît corroborer ma conjecture ici -->

Checking volume bitmap
Volume bitmap needs minor repair for orphaned blocks
Checking volume information
Invalid volume free block count
(It should be 21571106 instead of 5195815)
The volume Macintosh HD was found corrupt and needs to be repaired
File system check exit code is 8

En bref : il y a une erreur massive de décompte des blocs libres de la partition disk0s2 > qui (dans mes propres mots ici) interprète comme blocs "non-libres" une quantité considérable de blocs "libres" sans que que ces blocs ne correspondent pour autant à des écritures de fichiers. Cette erreur dans le système de fichiers (une incohérence en fait entre 2 de ses fichiers) > a pour conséquence une corruption relative du volume Macintosh HD qui monte sur la partition : il ne lui est reconnu que 22 Go d'espace libre alors qu'il ne recèle que 27 Go de fichiers écrits - 80 Go lui étant sucrés par l'erreur de l'allocation des blocs.

Pour réparer une erreur dans le système de fichiers > il faut que le volume qu'il conditionne soit démonté > afin que le système de fichiers soit "oisif".

Donc re-démarre ton Mac les 2 touches ⌘R pressées ensemble de l'écran noir jusqu'à l'affichage de la  (démarrage sur le RecoveryOS de secours > qui permet le démontage du volume de l'OS et donc la réparation de son système de fichiers) > lance l'«Utilitaire de Disque» > sélectionne le volume de l'OS (Macintosh HD) > et fais un S.O.S. dessus. Si tu obtiens à la fin la mention : "Le volume Macintosh HD paraît en bon état" --> c'est que l'erreur du système de fichiers aura été réparée.

Re-démarre alors normalement sur l'OS > et ta session ouverte > refais des vérifications > par exemple en repassant la commande :

df -H /

• cette commande retourne la mesure de l'occupation ou de la disponibilité des blocs en ce qui concerne le volume démarré

=> tu n'as qu'à poster ce tableau ici. Les 80 Go d'occupation fantôme devraient avoir disparu.

Congratulation !!! ton conseil a fait mouche...Bravo et MERCI !!!
J'ai relancé l'exécution de SOS, et le disque a été réparé.
J'ai récupéré les blocs disponibles, voir copie d'écran.

 

[Blue@512]

Vraiment, merci

pc16:~ Steve$ df -H /
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1   120G    29G    90G    25%  659864 4294307415    0%   /
pc16:~ Steve$

 

[Membre supprimé 1060554]

Blue

Le problème était intéressant, par son allure de paradoxe logique.

Parce qu'on admet a priori une identité entre : mesure des blocs occupés & mesure des fichiers recensés. Or dans ton cas > la mesure des blocs occupés était immensément plus étendue que celle des fichiers recensés : 107 Go de blocs occupés vs 27 Go de fichiers recensés. Il paraissait donc y avoir une faute contre le principe d'identité logique, càd. une contradiction.

À condition d'admettre comme également vraies les deux mesures qui se contredisaient. Pour réduire le paradoxe > il suffisait alors de conjecturer qu'une des deux mesures était erronée : alors, le paradoxe devenait simplement apparent, comme dans les vieux sophismes de l'Antiquité Grecque.

La mesure de l'allocation des blocs est du ressort d'un des fichiers du système de fichiers jhfs+ ; celle de la taille des fichiers, d'un autre de ses fichiers. La réduction du paradoxe revenait donc à le renvoyer à sa source : le système de fichiers jhfs+ > et à une antinomie entre deux de ses fichiers constituants.

J'ai opté dans ma conjecture pour une mesure correcte de la taille des fichiers et une mesure erronée de celle de l'allocation des blocs, pour une raison assez simple : c'est qu'un fichier relève d'un espace de répertoire monté qu'on appelle un « volume ». Cet espace de répertoire monté du volume a pour propriété : la « mise-en-lumière suffisante » (si je puis dire) - ce que les anciens philosophes Grecs appelaient l'« a-lêtheia » : le non-cèlement ou encore la vérité comme manifestation suffisante.

Cette absconse considération revient à dire ceci : dans l'espace de manifestation d'écriture qu'est un volume monté (monté, au sens de "déployant des écritures de blocs sous la forme de fichiers interprétables") > il n'y a pas d'autres fichiers existants que ceux qui s'y manifestent. Il y a une espèce d'e suffisance du plan de la manifestation qu'est le volume : ce qui n'y est pas trouvable comme fichier, n'y existe pas comme fichier.

Certes, le navigateur de fichiers qu'est le Finder se trouve affecté par des limitations graphiques sous ce regard : il n'affiche pas comme fichiers "visibles" les objets qui, soit portent des flags "hidden" (des marqueurs d'invisibilité graphique), soit sont désignés par un intitulé commençant par un « . ». Mais ces limitations d'affichage graphique n'affectent pas a priori des commandes textuelles du Terminal. Par exemple la commande du (disk_usage) sous la forme :

sudo du -shx /*

va bien recenser et mesurer tous les objets de premier ordre (fichiers simples ou dossiers mesurés en tant qu'ensembles de fichiers) de l'espace-racine du volume démarré - sans tenir compte des flags "hidden" (affectant par exemple des répertoires comme /private ou /usr).

C'est vrai que j'ai toujours un peu tendance dans ce type de cas à traiter les objets dont le nom commence par un . comme quantités négligeables et à les laisser hors décompte. En effet, comme l'a relevé justement bompi, la commande ci-dessus n'explore pas les objets (fichiers et dossiers) dotés d'un . au départ de leur intitulé. Pour être exact, j'aurais donc pu proposer comme commande un :

sudo find -x / \( -name '*' -o -name '^.' \) -d 1 -exec du -shx {} +

qui demande à l'utilitaire find de trouver aussi bien les objets dont le nom est quelconque que ceux dont le nom commence par un point - ce, en s'en tenant à une profondeur d'investigation de premier degré > avant de passer le lot à l'utilitaire du pour mesure des tailles. Cette commande dénuée d'élégance formelle joue bien son rôle, exécutivement parlant.

J'avais donc mise entre parenthèses la prise en compte des fichiers avec . en les supposant quantité négligeable a priori > pour concentrer la mesure sur tous les autres fichiers. En admettant donc qu'il n'existerait pas d'autres fichiers manifestes que ceux mesurés par la commande, soit 27 Go.

Assuré de cette « évidence » > il ne restait plus qu'à incriminer la gestion de l'allocation des blocs de la partition, en supposant qu'un certain nombre de blocs qui ne donnaient pas lieu à un affichage des écritures sous forme de fichiers dans l'espace de manifestation du volume > n'étaient pas pour autant marqués comme vacants (pour des écritures) > mais comme occupés (par des écritures ne donnant pourtant pas lieu à un affichage de fichiers).

Régulièrement parlant, les blocs évalués comme "occupés" par des écritures donnent lieu à un affichage sous forme de fichiers dans l'espace de manifestation du volume ; tandis que les blocs évalués comme "vacants" ne donnent lieu à aucun manifestation sous forme de fichiers. Il suffisait de conjecturer qu'un certain nombre de blocs était faussement évalués comme "occupés" > alors même qu'il ne donnaient lieu à aucun affichage sous forme de fichiers dans le volume.

Cette absconse dialectique équivalait à incriminer le gestionnaire de l'allocation des blocs de "défaut de mise à jour" et donc à lui faire porter le chapeau de l'erreur. Ce qui semble bien avoir été le cas > une remise à jour de ce fichier ayant fait disparaître le décompte des blocs pseudo-"occupés".

 

[Blue@512]

Blue

Le problème était intéressant, par son allure de paradoxe logique.

Parce qu'on admet a priori une identité entre : mesure des blocs occupés & mesure des fichiers recensés. Or dans ton cas > la mesure des blocs occupés était immensément plus étendue que celle des fichiers recensés : 107 Go de blocs occupés vs 27 Go de fichiers recensés. Il paraissait donc y avoir une faute contre le principe d'identité logique, càd. une contradiction.

À condition d'admettre comme également vraies les deux mesures qui se contredisaient. Pour réduire le paradoxe > il suffisait alors de conjecturer qu'une des deux mesures était erronée : alors, le paradoxe devenait simplement apparent, comme dans les vieux sophismes de l'Antiquité Grecque.

La mesure de l'allocation des blocs est du ressort d'un des fichiers du système de fichiers jhfs+ ; celle de la taille des fichiers, d'un autre de ses fichiers. La réduction du paradoxe revenait donc à le renvoyer à sa source : le système de fichiers jhfs+ > et à une antinomie entre deux de ses fichiers constituants.

J'ai opté dans ma conjecture pour une mesure correcte de la taille des fichiers et une mesure erronée de celle de l'allocation des blocs, pour une raison assez simple : c'est qu'un fichier relève d'un espace de répertoire monté qu'on appelle un « volume ». Cet espace de répertoire monté du volume a pour propriété : la « mise-en-lumière suffisante » (si je puis dire) - ce que les anciens philosophes Grecs appelaient l'« a-lêtheia » : le non-cèlement ou encore la vérité comme manifestation suffisante.

Cette absconse considération revient à dire ceci : dans l'espace de manifestation d'écriture qu'est un volume monté (monté, au sens de "déployant des écritures de blocs sous la forme de fichiers interprétables") > il n'y a pas d'autres fichiers existants que ceux qui s'y manifestent. Il y a une espèce d'e suffisance du plan de la manifestation qu'est le volume : ce qui n'y est pas trouvable comme fichier, n'y existe pas comme fichier.

Certes, le navigateur de fichiers qu'est le Finder se trouve affecté par des limitations graphiques sous ce regard : il n'affiche pas comme fichiers "visibles" les objets qui, soit portent des flags "hidden" (des marqueurs d'invisibilité graphique), soit sont désignés par un intitulé commençant par un « . ». Mais ces limitations d'affichage graphique n'affectent pas a priori des commandes textuelles du Terminal. Par exemple la commande du (disk_usage) sous la forme :

sudo du -shx /*

va bien recenser et mesurer tous les objets de premier ordre (fichiers simples ou dossiers mesurés en tant qu'ensembles de fichiers) de l'espace-racine du volume démarré - sans tenir compte des flags "hidden" (affectant par exemple des répertoires comme /private ou /usr).

C'est vrai que j'ai toujours un peu tendance dans ce type de cas à traiter les objets dont le nom commence par un . comme quantités négligeables et à les laisser hors décompte. En effet, comme l'a relevé justement bompi, la commande ci-dessus n'explore pas les objets (fichiers et dossiers) dotés d'un . au départ de leur intitulé. Pour être exact, j'aurais donc pu proposer comme commande un :

sudo find -x / \( -name '*' -o -name '^.' \) -d 1 -exec du -shx {} +

qui demande à l'utilitaire find de trouver aussi bien les objets dont le nom est quelconque que ceux dont le nom commence par un point - ce, en s'en tenant à une profondeur d'investigation de premier degré > avant de passer le lot à l'utilitaire du pour mesure des tailles. Cette commande dénuée d'élégance formelle joue bien son rôle, exécutivement parlant.

J'avais donc mise entre parenthèses la prise en compte des fichiers avec . en les supposant quantité négligeable a priori > pour concentrer la mesure sur tous les autres fichiers. En admettant donc qu'il n'existerait pas d'autres fichiers manifestes que ceux mesurés par la commande, soit 27 Go.

Assuré de cette « évidence » > il ne restait plus qu'à incriminer la gestion de l'allocation des blocs de la partition, en supposant qu'un certain nombre de blocs qui ne donnaient pas lieu à un affichage des écritures sous forme de fichiers dans l'espace de manifestation du volume > n'étaient pas pour autant marqués comme vacants (pour des écritures) > mais comme occupés (par des écritures ne donnant pourtant pas lieu à un affichage de fichiers).

Régulièrement parlant, les blocs évalués comme "occupés" par des écritures donnent lieu à un affichage sous forme de fichiers dans l'espace de manifestation du volume ; tandis que les blocs évalués comme "vacants" ne donnent lieu à aucun manifestation sous forme de fichiers. Il suffisait de conjecturer qu'un certain nombre de blocs était faussement évalués comme "occupés" > alors même qu'il ne donnaient lieu à aucun affichage sous forme de fichiers dans le volume.

Cette absconse dialectique équivalait à incriminer le gestionnaire de l'allocation des blocs de "défaut de mise à jour" et donc à lui faire porter le chapeau de l'erreur. Ce qui semble bien avoir été le cas > une remise à jour de ce fichier ayant fait disparaître le décompte des blocs pseudo-"occupés".

CQFD, souhaitant que d'autres membres de la communauté puissent bénéficier de ces connaissances.

 

[Rémi Lefebvre]

Bonjour à tous,

J'ai essayé tant bien que mal de suivre les différentes réponses de ce sujet pour régler mon propre problème d'espace système (je crois détenir le record avec 543,51 Go quand même...)

Je vais essayer d'être le plus clair possible afin e vous éviter de redémarrer toutes vos explications à 0.

Je suis sous Sierra 12.0.6, je fais un gros nettoyage de mes ordis (MacBook Pro et iMac) afin de repartir sur quelque chose d'organisé et bien géré.

J'ai une TimeCapsule un peu vieille (USB 2.0, ethernet Gigabits et 802.11n Wi-Fi) sur laquelle je vais sauvegarder mon iMac et mon MacBook Pro.
J'ai donc trier pour tout virer de mon iMac mes dossier vidéos, photos, ect.. Pour ne garder que les applications et travailler avec les médias sur un disque dur externe, mais je voulais quand même avant de tout virer les documents sur disque dur externe faire une sauvegarde TimeMachine avec mes documents dessus, au cas ou. Mais voyant le temps de sauvegarde s'éterniser, je me suis dit qu'il fallait peut-être alléger la taille du "système" avant de sauvegarder inutilement tout ça...

Bon, jusque là ça va.

Suite à vos conseils, j'ai réussi à déterminer que mon système ne pesait que 10Go et quelques mais que mon dossier utilisateur pesait 900Go quand même... Alors qu'en calculant je ne trouvais que 500Go à peine.

J'ai fais la manipulation "Tu vas taper la commande :
hdiutil create toto -size 120g
tu vas attendre que la création soit terminée
puis tu vas faire
rm toto.dmg
puis refaire un
df -H

Tout ceci pour "forcer" le système à libérer de la place." et ai effectivement gagné près de 120Go.

Mais à je me suis emmêlé les pinceaux, j'essaye de faire les autres opérations en tapant mon mot de passe quand il m'est demandé et ça me met du "access denied" ou "illégal option --"... bref, je suis paumé et j'ose pas faire n'importe quoi pour le regretter ensuite...

Je suis donc tout ouïe pour suivre vos conseils ; j'ai bien désactiver la sauvegarde automatique de TimeCapsule pour éviter toutes fausses infos et j'ai donc interrompu la première sauvegarde mais je ne l'ai pas débranché.

La manip "sudo du -sh /.*" me donne ceci :

961G /.

961G /..

16K /.DS_Store

43M /.DocumentRevisions-V100

4,2G /.PKInstallSandboxManager-SystemSoftware

786M /.Spotlight-V100

0B /.file

26M /.fseventsd

0B /.vol

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

et "sudo du -sxg /* | sort -nr" ceci :

900 /Users

37 /Applications

10 /System

6 /Library

5 /private

1 /var

1 /usr

1 /tmp

1 /sbin

1 /net

1 /installer.failurerequests

1 /home

1 /file

1 /etc

1 /dev

1 /bin

1 /Volumes

0 /cores

0 /Network

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

Que donc faire ensuite ? c'est à partir de ce moment là que je n'arrivais plus à suivre... Comme je vous l'ai dit, mon dossier Users devrait faire que 500Go à peu près selon moi...

Merci beaucoup !

 

[Deleted member 1099514]

Fais :
sudo du -sxg /Users/*/* | sort -nr

 

[Rémi Lefebvre]

Bonjour jeanjd63 et merci de prendre le temps de me répondre voici ce que ça me donne :

556 /Users/RemiLefebvre/Library

342 /Users/RemiLefebvre/Desktop

2 /Users/RemiLefebvre/Downloads

1 /Users/Shared/adi

1 /Users/Shared/Red Giant

1 /Users/Shared/AvidMediaComposer

1 /Users/Shared/AdobeInstalledCodecs

1 /Users/Shared/Adobe

1 /Users/RemiLefebvre/isus

1 /Users/RemiLefebvre/Public

1 /Users/RemiLefebvre/Pictures

1 /Users/RemiLefebvre/Music

1 /Users/RemiLefebvre/Documents

1 /Users/RemiLefebvre/Creative Cloud Files (archived) (1)

1 /Users/RemiLefebvre/Creative Cloud Files

0 /Users/Shared/SC Info

0 /Users/Shared/Marquee

0 /Users/Shared/Documents

0 /Users/Shared/AvidBinIndexer

0 /Users/Shared/Avid

0 /Users/Shared/AVX Plug-Ins Data

0 /Users/RemiLefebvre/Movies

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

Un gros poids dans la librairies apparemment ?

 

[Deleted member 1099514]

du -sgx Library/* | sort - nr

 

[Rémi Lefebvre]

iMac-de-Remi-Lefebvre:~ RemiLefebvre$ du -shx Library/* | sort - nr

sort: stat failed: nr: No such file or directory

du: Library/Saved Application State/com.meldaproduction.setup.savedState: Permission denied

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

 

[Deleted member 1099514]

iMac-de-Remi-Lefebvre:~ RemiLefebvre$ du -shx Library/* | sort - nr

sort: stat failed: nr: No such file or directory

du: Library/Saved Application State/com.meldaproduction.setup.savedState: Permission denied

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

Sur une seule ligne la commande.

 

[Rémi Lefebvre]

Je ne comprends pas sur un seule ligne, c'est bien ce que j'ai tenté de faire ? J'ai copié/collé votre ligne après avoir fait "entrer" et non avant, pour bien coller la ligne après "iMac-de-Remi-Lefebvre:~ RemiLefebvre$", et ça me met la même chose que je vous ai répondu

 

[Deleted member 1099514]

C'est la faute au smartphone :

du -sxg Library/* | sort -nr

 

[Rémi Lefebvre]

Ah effectivement, ça marche mieux :

543 Library/Caches

10 Library/Application Support

3 Library/Containers

1 Library/instance

1 Library/com.apple.nsurlsessiond

1 Library/WebKit

1 Library/SyncedPreferences

1 Library/Suggestions

1 Library/Spelling

1 Library/Sharing

1 Library/Saved Application State

1 Library/Safari

1 Library/PubSub

1 Library/Preferences

1 Library/Personas

1 Library/Passes

1 Library/Mobile Documents

1 Library/Metadata

1 Library/Messages

1 Library/Mail

1 Library/Logs

1 Library/LaunchAgents

1 Library/LanguageModeling

1 Library/Keychains

1 Library/KeyboardServices

1 Library/Keyboard

1 Library/IdentityServices

1 Library/Group Containers

1 Library/Fonts

1 Library/Dictionaries

1 Library/CoreFollowUp

1 Library/CoreData

1 Library/Cookies

1 Library/Calendars

1 Library/Assistant

1 Library/Address Book Plug-Ins

1 Library/Accounts

0 Library/iTunes

0 Library/iMovie

0 Library/Voices

0 Library/Sounds

0 Library/Services

0 Library/Screen Savers

0 Library/Printers

0 Library/PreferencePanes

0 Library/PhotoshopCrashes

0 Library/Maps

0 Library/Keyboard Layouts

0 Library/Internet Plug-Ins

0 Library/Input Methods

0 Library/GameKit

0 Library/FontCollections

0 Library/Favorites

0 Library/Compositions

0 Library/Colors

0 Library/ColorSync

0 Library/ColorPickers

0 Library/CallServices

0 Library/Audio

0 Library/Assistants

0 Library/Application Scripts

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

 

[Deleted member 1099514]

du -sxg Library/Caches/* | sort -nr

 

[Rémi Lefebvre]

iMac-de-Remi-Lefebvre:~ RemiLefebvre$ du -sxg Library/Caches/* | sort -nr

541 Library/Caches/Adobe

2 Library/Caches/com.spotify.client

1 Library/Caches/storeassetd

1 Library/Caches/storeaccountd

1 Library/Caches/mbuseragent

1 Library/Caches/ksurl

1 Library/Caches/com.skype.skype

1 Library/Caches/com.redgiant.Link

1 Library/Caches/com.nvidia.CUDAPref.501

1 Library/Caches/com.linvo.stremio

1 Library/Caches/com.apple.systempreferences

1 Library/Caches/com.apple.siri.bundleservicecache.plist

1 Library/Caches/com.apple.safaridavclient

1 Library/Caches/com.apple.preferencepanes.usercache

1 Library/Caches/com.apple.preferencepanes.searchindexcache

1 Library/Caches/com.apple.passd

1 Library/Caches/com.apple.parsecd

1 Library/Caches/com.apple.nsservicescache.plist

1 Library/Caches/com.apple.nbagent

1 Library/Caches/com.apple.keyboardservicesd

1 Library/Caches/com.apple.installer

1 Library/Caches/com.apple.imfoundation.IMRemoteURLConnectionAgent

1 Library/Caches/com.apple.icloud.fmfd

1 Library/Caches/com.apple.iWork.Pages

1 Library/Caches/com.apple.iLifeMediaBrowser

1 Library/Caches/com.apple.iCloudHelper

1 Library/Caches/com.apple.iChat

1 Library/Caches/com.apple.helpviewer

1 Library/Caches/com.apple.helpd

1 Library/Caches/com.apple.gamed

1 Library/Caches/com.apple.finder

1 Library/Caches/com.apple.dashboard.client

1 Library/Caches/com.apple.commerce.spotlight

1 Library/Caches/com.apple.commerce.safari

1 Library/Caches/com.apple.commerce

1 Library/Caches/com.apple.cache_delete

1 Library/Caches/com.apple.automator.actionCache-system-standardLocations.plist

1 Library/Caches/com.apple.automator.actionCache-bundleLocations.plist

1 Library/Caches/com.apple.appstore

1 Library/Caches/com.apple.akd

1 Library/Caches/com.apple.airport.airportutility

1 Library/Caches/com.apple.Spotlight

1 Library/Caches/com.apple.Safari

1 Library/Caches/com.apple.QuickLookDaemon

1 Library/Caches/com.apple.Messages

1 Library/Caches/com.apple.DictionaryServices

1 Library/Caches/com.apple.AddressBookSourceSync

1 Library/Caches/com.adobe.accmac

1 Library/Caches/com.adobe.acc.AdobeDesktopService

1 Library/Caches/com.adobe.Photoshop

1 Library/Caches/com.adobe.PDApp

1 Library/Caches/QCCompositionRepository-com.apple.iTunes.cache

1 Library/Caches/PassKit

1 Library/Caches/Metadata

1 Library/Caches/Maps

1 Library/Caches/GeoServices

1 Library/Caches/GameKit

1 Library/Caches/FamilyCircle

1 Library/Caches/CloudKit

1 Library/Caches/CSXS

1 Library/Caches/Adobe Camera Raw

1 Library/Caches/$(CFBundleIdentifier)

0 Library/Caches/stremio

0 Library/Caches/storedownloadd

0 Library/Caches/qlmanage

0 Library/Caches/com.plausiblelabs.crashreporter.data

0 Library/Caches/com.malwarebytes.antimalware

0 Library/Caches/com.malwarebytes.Malwarebytes-XPC-Service

0 Library/Caches/com.apple.nsurlsessiond

0 Library/Caches/com.apple.mobilenotes.persistentstoreopen.lock

0 Library/Caches/com.apple.mail

0 Library/Caches/com.apple.ibooks

0 Library/Caches/com.apple.iTunes

0 Library/Caches/com.apple.bird

0 Library/Caches/com.apple.XprotectFramework.AnalysisService

0 Library/Caches/com.apple.CommerceKit.TransactionService

0 Library/Caches/com.apple.AOSPushRelay

0 Library/Caches/com.adobe.illustrator

0 Library/Caches/com.adobe.crashreporter

0 Library/Caches/com.adobe.LogTransport.LogTransport

0 Library/Caches/com.adobe.AASIapp

0 Library/Caches/UpdateEngine-Temp

0 Library/Caches/Photos_Cache.noindex

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

 

[Deleted member 1099514]

du -sxg Library/Caches/Adobe/* | sort -nr

 

[Rémi Lefebvre]

Ce qui m'interroge, c'est pourquoi les applications comme Onyx ne font pas ces manipulations toutes seules quand on fait un nettoyage par défaut ? Il faut peut-être bien les configurer aussi me direz-vous...

 

[Rémi Lefebvre]

iMac-de-Remi-Lefebvre:~ RemiLefebvre$ du -sxg Library/Caches/Adobe/* | sort -nr

541 Library/Caches/Adobe/After Effects

1 Library/Caches/Adobe/Premiere Pro

1 Library/Caches/Adobe/PhotoshopServer

1 Library/Caches/Adobe/PProHeadless

1 Library/Caches/Adobe/Experimentation

1 Library/Caches/Adobe/Color

1 Library/Caches/Adobe/CCX Welcome

1 Library/Caches/Adobe/Audition

1 Library/Caches/Adobe/Adobe Media Encoder

0 Library/Caches/Adobe/Flash Player

0 Library/Caches/Adobe/Butler

iMac-de-Remi-Lefebvre:~ RemiLefebvre$

 

[Deleted member 1099514]

À toi la main

 

[alessmuse]

Bonjour,
je suis en train de faire la même manipulation que Rémi (décidément c'est la saison des purges), car je viens de découvrir que j'ai 157,97 go de mémoire système.... en dehors du fait que depuis la maj High Sierra effectuée il y a une heure qui a pour conséquence une grande lenteur du Mac (Pro mi 2012, 750 go/ 8go, mais ça on verra plus tard), la commande hdiutil create toto -size 120g est très longue à aboutir... est-ce normal? (série de . qui arrivent très lentement....)
Merci!