Dossier caché "cores" sur macosx tiger

[julpos]

Bonjour, j'ai un Macbook Intel 2Ghz, mémoire 2Go sous Mac osx 10.4.9. , 120 Go de disque dur.

J'ai remarqué d'énormes problème d'espaces disque. J'arrivai parfois à 50 mo de dispo sur le disque principal ! Bon ok j'avais beaucoup de films, de fichiers, etc... mais après avoir effacé tous mes films, toutes mes photos et toute ma musique il me reste de libre que 3 Go seulement ! Alors je télécharge et j'installe le soft "OmniDiskSweeper" pour mieux explorer mon mac et ainsi voir ce qui prend le plus d'espace. Je coche sur Onyx l'option pour afficher les fichiers cachés et je découvre un dossier caché nommé "cores" qui pèse 70 Go situé dans la racine de Macintosh HD. 70 Go ! Et quand j'esseye de le mettre dans la corbeille, c'est bien ce que je pensai, il me demande mon mot de passe, donc un élément important apparement qui fait partie intégrante du système. Je trouve ça quand même bizarre qu'il pèse autant en espace disque.

Et comme j'ai pas envie de faire une connerie je fais appel à vous !

Pouvez vous tester déjà voir si vous avez tous le même dossier caché ? Si oui pèse-t-il autant ?

Est - ce normal ? A quoi ça sert ? Est - ce indispensable au bon fonctionnement du système OSX ?

Si j'efface ce dossier, est-ce que j'aurai des soucis au démarage (kernel panics ou blocage divers...) ?


Merci beaucoup d'avance pour vos réactions. J'espère avoir des réponses d'informaticiens spécialistes dans la structure Mac OS X !

 

[Bebop 4]

Salut julpos

Je viens de lancer Onyx sur mon mac, et j'ai aussi un dossier invisible nommé "Cores" à la racine du HD. Je suis sur G4 digital audio 466 MHz, 1.5 Go Ram, 2 disques durs 20 Go chaque, mac OS Tiger 10.4.11. Dans mon cas, ce dossier contient le grand total de 0 Ko. Je ne connais pas tout les aspects de mac OS X, mais je suppose que ce dossier a son utilité. Que contient ton dossier ? À 70 Go, moi aussi je me poserais des questions. Malheureusement, je ne peux t'aider plus.

 

[Manic]

Ce dossier sur mon Mac a également vide. D'après ce que j'ai pu trouver comme infos avec mon ami Google, ce dossier contiendrait des images de la mémoire de l'ordinateur pour des raisons de déboggage après un plantage ou le redémarrage forcé de l'ordinateur. Mais appararent ce dossier devrait également être vide en tout temps...

Mon conseil: vider le contenu du dossier et non pas supprimer le dossier lui-même.

Un truc: pour voir la taille maximal alloué pour les fichiers «core», taper ulimit -a dans le Terminal. Normalement cela devrait être à 0 (zéro).

 

[bompi]

Je suppose qu'il y a des plantages sur cette machine ... Les fichiers en question sont des core dumps bien connus des amateurs d'UNIX.

Sauf à vouloir debugger soi-même le système ou les applications responsables de ces fichiers, on peut les supprimer. Mais, effectivement, ne pas supprimer le répertoire.

Ensuite, deux options :
a) on préfère ne pas savoir ce qui se passe et on se débrouille pour que le système ne crée plus ce type de fichiers
b) on cherche la cause de la création de ces fichiers, soit : quelle est l'application qui plante aussi souvent

Pour le a), tu peux aller voir ici, où le bloggeur donne les indications idoines.

 

[julpos]

Merci pour vos réponses. Tout d'abord pour répondre à Manic, j'ai tapé ta ligne de commande sur le terminal et voici ce que j'ai obtenu comme information :

core file size (blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 266
virtual memory (kbytes, -v) unlimited
ordinateur-de-julpos:~ julpos$

Quelqu'un peut m'éclairer sur ce que je doit comprendre ? Apparement ça confirme bien les 70 Go avec la ligne : "stack size (kbytes, -s) 8192" , non ?

Quand au problème de plantage où Bompi suppose que mon ordi doit planter souvent, je répondrai qu'en fait il tourne tout à fait normalement, j'ai eu depuis qu'un seul gros souci,c'est un grave kernel panic que j'avais provoqué à l'époque où je jouai les apprentis sorcier : bootcamp et parrallels qui tournait sur la partition de bootcamp et où comme un bourrin j'avais attribué toute la mémoire sur parrellel ! Donc j'ai été chez le fabriquant qui m'a débloquer tout ça.

Et depuis tout va pour le mieux il plante quasiment jamais. Par contre j'ai l'impression que quand VMWARE FUSION tourne, il se passe peut être des trucs bizarre et c'est peut-être à ce moment là que ces fichiers se créent.

Donc si je résume bien j'efface pas le répertoire mais les fichiers c'est ça ? Serait - ce pas mieux si avant j'effectue un back up avec carbon copy cloner par exemple ? Où je peux y aller tranquille ?

 

[hippo sulfite]

Merci pour vos réponses. Tout d'abord pour répondre à Manic, j'ai tapé ta ligne de commande sur le terminal et voici ce que j'ai obtenu comme information :

core file size (blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 266
virtual memory (kbytes, -v) unlimited
ordinateur-de-julpos:~ julpos$

Quelqu'un peut m'éclairer sur ce que je doit comprendre ? Apparement ça confirme bien les 70 Go avec la ligne : "stack size (kbytes, -s) 8192" , non ?

Euh, il me somble que 8192 kBytes = 8 MO et pas 70 GO.

 

[bompi]

Puisque tu es dans le Terminal, tu peux faire un :

ls -l /cores

pour nous afficher la liste des fichiers concernés.

Note que je n'ai pas dit que ton système plante mais qu'une application (voire plusieurs) plante régulièrement.
Normalement, en chargeant le core dump dans le debuggeur, on doit récupérer le nom du processus qui a planté.

 

[julpos]

Oui je confirme c'est bien VMWARE FUSION qui engendre la création de gros fichiers dans le dossier caché "cores", fichier de moyenne 398 Mo ! Et voici ce que j'ai eu dans le terminal :

-r-------- 1 julienca admin 413569024 Jul 6 21:18 core.320
-r-------- 1 julienca admin 413569024 Jul 6 21:24 core.321
-r-------- 1 julienca admin 413569024 Jul 6 21:25 core.322
-r-------- 1 julienca admin 414429184 Jul 6 21:28 core.338
-r-------- 1 julienca admin 414429184 Jul 6 21:29 core.339
-r-------- 1 julienca admin 412913664 Jul 7 13:09 core.382
-r-------- 1 julienca admin 427536384 Jun 18 11:21 core.433
-r-------- 1 julienca admin 427536384 Jun 18 11:23 core.462
-r-------- 1 julienca admin 427536384 Jun 18 11:24 core.466
-r-------- 1 julienca admin 427536384 Jun 18 11:24 core.480
-r-------- 1 julienca admin 427536384 Jun 18 11:25 core.485
-r-------- 1 julienca admin 416038912 Jul 7 13:11 core.579
-r-------- 1 julienca admin 427536384 Jun 18 11:28 core.598
-r-------- 1 julienca admin 427536384 Jun 18 11:29 core.625
-r-------- 1 julienca admin 417107968 Jul 6 21:54 core.638
-r-------- 1 julienca admin 417107968 Jul 6 21:55 core.639
-r-------- 1 julienca admin 427536384 Jun 18 11:30 core.641
-r-------- 1 julienca admin 417107968 Jul 6 22:00 core.642
-r-------- 1 julienca admin 427536384 Jun 18 11:31 core.643
-r-------- 1 julienca admin 427536384 Jun 18 11:33 core.647
-r-------- 1 julienca admin 427536384 Jun 18 11:36 core.648
-r-------- 1 julienca admin 427536384 Jun 18 11:37 core.673
-r-------- 1 julienca admin 427536384 Jun 18 11:39 core.705
-r-------- 1 julienca admin 427536384 Jun 18 11:40 core.713
-r-------- 1 julienca admin 427536384 Jun 18 11:41 core.716
-r-------- 1 julienca admin 427536384 Jun 18 11:44 core.719
-r-------- 1 julienca admin 427536384 Jun 18 11:45 core.720
-r-------- 1 julienca admin 427536384 Jun 18 11:46 core.723
-r-------- 1 julienca admin 427536384 Jun 18 11:47 core.725
-r-------- 1 julienca admin 427536384 Jun 18 11:49 core.726
-r-------- 1 julienca admin 416038912 Jul 7 13:14 core.765
-r-------- 1 julienca admin 416038912 Jul 7 13:16 core.766
-r-------- 1 julienca admin 416038912 Jul 7 13:18 core.767
-r-------- 1 julienca admin 416038912 Jul 7 13:21 core.768

 

[piercoco]

Bonjour,

j'ai exactement le même résultat sur la commande "ulimit -a", mais absolument rien sur la commande "ls -l /cores" ???

 

[Manic]

core file size (blocks, -c) 0

C'est surtout cette ligne qui nous intéresse. La taille des fichiers core devrait être zéro, tout est normal de ce côté là. Mais pour une autre raison, le système les gardent dans le dossier et finissent par s'accumuler.

 

[bompi]

Bref, on peut virer ces fichiers sans état d'âme. Reste à savoir pourquoi VMWare Fusion se plante ainsi.

 

[julpos]

Un dernier post pour clore ce sujet. Merci tout d'abord pour vos éléments de réponses qui m'ont confortés dans mes choix.

Donc oui c'est bel et bien VMWARE qui crée ces fichiers à la con sans les effacer : 4 fichier en moyenne de 400 Mo dans une minute ! J'ai pu finalement tous les effacer pour arriver à 80 Go d'espace libre ! Je respire enfin... quant à VMWARE, j'ai déplacé ma machine virtuelle XP sur un disque dur externe et effacé l'originale sur l'ordi. Depuis que je le fais tourner sur le disque dur externe, ça va beaucoup plus vite et plus aucun fichiers crées !

Merci à très bientôt

 

[nikito]

Je suppose qu'il y a des plantages sur cette machine ... Les fichiers en question sont des core dumps bien connus des amateurs d'UNIX.

Sauf à vouloir debugger soi-même le système ou les applications responsables de ces fichiers, on peut les supprimer. Mais, effectivement, ne pas supprimer le répertoire.

Ensuite, deux options :
a) on préfère ne pas savoir ce qui se passe et on se débrouille pour que le système ne crée plus ce type de fichiers
b) on cherche la cause de la création de ces fichiers, soit : quelle est l'application qui plante aussi souvent

Pour le a), tu peux aller voir ici, où le bloggeur donne les indications idoines.

Bonjour,

je viens de rencontrer ce problème qui a satuté mon DD ; aussi, je serais intéressé par la mise en oeuvre de l'option b) .

Merci

nicolas

 

[bompi]

Bonjour,
pour cela il faut utiliser le debuggeur et charger le fichier “core” à examiner pour trouver l’application qui a provoqué l’erreur.
Ensuite… tout dépend de quelle application il s’agit et de comment elle a été créée (au moment de sa compilation).

Cela fait bien longtemps que je n’ai pas fait ça mais jadis il fallait que l’application ait été compilée avec une génération d’informations qui permet de s’y retrouver plus aisément mais alourdit considéablement l’exécutable.

Et par ailleurs, sans avoir les sources de l’application, on ne peut pas aller très loin.

Si ce n’est pas ton application ni un projet open source, tu ne pourras pas aller très loin.