Est-ce que d’autre utilisateurs de KDE ont, comme moi un tel dossier :
~/.kde/tmp-sid-sda8 (‘sid-sda8’ étant le nom de la machine)
Je viens de voir qu’il avait 2500 dossiers pour un poids total de 6 Go 
Il doit emmagasiner un wagon de trucs depuis un certain temps pour ça ?
Ça va être viré mais je contrôlerai plus fréquemment maintenant.
Salut,
6 Gio pour ton dossier tmp 
[code]root@Debian-pc-1:/home/pc-1-loreleil/.kde/tmp-Debian-pc-1# du -hs
325K .
[/code]
root@Debian-pc-1:/home/pc-1-loreleil/.kde/tmp-Debian-pc-1# du -ha | more
1,0K ./plasma-desktoppb3094.tmp
0 ./closeditems/_1.118
1,0K ./closeditems
1,0K ./plasma-desktopqm3094.tmp
1,0K ./plasma-desktopKt3094.tmp
1,0K ./plasma-desktopCk3094.tmp
1,0K ./konqueror-crash-S30208.log
53K ./konsolewZ9870.tmp
1,0K ./konsoleTi9870.tmp
1,0K ./plasma-desktopNM3094.tmp
1,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/cron.gif
3,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/file.png
1,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/icon_post_delete.gif
9,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/stylesheet.css
2,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/icon_post_edit.gif
1,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/spacer.gif
4,0K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers/100x100xfile.jpg
22K ./konquerorTN3415.tmp/probleme-de-boot-t33635_fichiers
208K ./konquerorTN3415.tmp/probleme-de-boot-t33635.html
231K ./konquerorTN3415.tmp
1,0K ./plasma-desktopCY3094.tmp
1,0K ./konsoleTT9870.tmp
295K .
root@Debian-pc-1:/home/pc-1-loreleil/.kde/tmp-Debian-pc-1#
çà me paraît excessif, d’un autre côté les “tmp” sont sensés se vider au redémmarrage, non ?
Maintenant si tu n’as pas rebooter ta machine depuis des lustres, alors … 
En espèrant 
que tu n’est pas 100 dossiers tmp comme celui-ci sur ta bécanne, accroche toi jeannot !!! 
Ben c’est bien ce qui m’inquiète.
Ma machine est en général reboutée une fois par semaine, quand je fais la MAJ après avoir sauvegardé. Le maxi est une semaine donc ce n’est pas à proprement parler un .tmp.
Au lieu de tout virer, j’ai déplacé sur une autre ‘partition garage’ pour pouvoir les étudier de façon plus approfondie quant aux dated et aux contenus.
Le déplacement n’est pas encore terminé mais il y a “en tout” 27 830 dossiers pour 368 199 fichiers 
J’ai l’impression que le côté “tmp-sid-sda8” n’a rien à voir avec un ‘.tmp’
Ne serait-ce pas le résultat de tes tentatives d’encodage 
Ce n’est pas impossible 
La copie sera terminée dans peu de temps et dans la soirée, j’éplucherai un peu ces fichiers. Je tiendrai au courant.
J’ai vu ton fichier dans le fil Google+, c’est chromnium ton navigateur ?
Non, IW.
Bon en fait, ce sont des fichiers de cache surtout.
Le problème, c’est que je ne comprends pas pourquoi ils s’acculent ?
J’en ai retrouvé qui dataient de 2 ans
Du coup de leur élimination, mon ~/ s’en trouve allégé 
Je surveillerais régulièrement mais je pose quand même la question :
quoi faire pour que ces fichier soient éliminé d’office ?
Il ne s’agit pas du cache de IW, qui lui, fonctionne à chaque fermeture.
Je ne parle pas d’un script.
S’il n’y avait pas d’autres moyens, j’y viendrais.
Salut
Normalement le /tmp est vidé à chaque démarrage.
Il faut vérifier si dans /etc/default/rcS il y a :
TMPTIME=0Le script qui vide le /tmp est : /etc/init.d/mountall-bootclean.sh
Au démarrage il doit y avoir :
Merci pour ces renseignements, je vois ça ce soir. 
Salut,
Je crois que ça n’a rien à voir…
/tmp et ~/.kde/tmp-sid-sda8 sont différents… 
[quote="/etc/init.d/mountall-bootclean.sh"]
…
Clean /tmp, /var/lock, /var/run
…
[/quote]…a moins de personnaliser le script.
Ah oui 
J’ai cru à /tmp
La prochaine fois j’irai lire moins vite
En tous cas, ça m’a permis de voir que dans /var/tmp, il y avait un wagon de merdes qui s’accumulent, dont : kdecache-ricardo
Je ne sais pas jusqu’où je peux aller dans le vidage de ce dossier ?
Votre avis ?
Si c’est du TMP alors il n’y a aucun risque de les supprimer. Au pire tu auras un programme en cours qui ne t’autorisera pas à en supprimer quelques un mais rien de plus.
Merci de ta réponse, je vais le copier quelque part en attendant et je vais tester pendant quelques jours.
C’est faux. C’est très rare sous linux, d’utiliser des vérrous sur les fichiers. Si un programme lis un fichier et que tu le supprime pendant sa lecture, ça supprime le fichier, mais le programme pourras toujours le lire. En fait le fichier n’est plus accessible par le système de fichier mais les descripteurs de fichier en cours d’utilisation ne sont pas invalidés.
c’est des “inode” que tu parles ?
L’inode c’est le descripteur de fichier (ce qui représente le fichier) dans le système de fichier. Je pensais plutôt à celui attribué en mémoire par le noyau.
L’inode est une zone mémoire du système de fichier qui va donner toutes les métadonnées du fichier et indiquer où il se trouve dans le reste du système de fichier.
Le descripteur de fichier vu par un programme et un simple numéro. En fait chaque programme du système d’exploitation possède une table de descripteurs de fichier (de taille fixe, ~250 je crois). Quand le programme ouvre un fichier (avec open par exemple), le noyau va chercher le premier descripteur libre et va y associer le fichier qu’il viens d’ouvrir (par exemple, par défaut les 3 premier sont déjà alloués par l’entrée et la sortie standard ainsi que la sortie d’erreur).
Si le noyau reçoit un unlink du fichier ouvert, l’inode ne seras plus accessible, mais le descripteur déjà alloué ne seras pas libéré.
Je vais parler en C, il existe des représentation de plus au niveau dans d’autres langages (et même en C), mais elles ne font qu’encapsuler ça.
Ça se test facilement avec deux shells :
[ul]
[li]un qui execute une boucle de lecture lente :
[code]
#!/bin/bash
while read ; do
echo "${REPLY}"
sleep 2
done < “$1”
[/code][/li]
[li]l’autre qui supprime le fichier en cours de lecture.[/li][/ul]
@Misterfreez : C’est pour cela que j’ai mis “au pire”. Mais c’est vrai que je n’aais jamais fait attention à cette différence avec le system redmondien