Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Finder qui prend tout le CPU

12 réponses
Avatar
olivier.marti
Bonjour,

Depuis quelques jours, je constate que le Finder prend en permance 60 à
100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
CPU de Menu Meter dans la barre de menu). Ce problème résiste à
plusieurs redémmarrages.

Ca ne me parait pas normal, mais je ne sais pas comment faire un
diagnostic plus précis et corriger ça.

Une idée ?

Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
alors le processus mds prendre le CPU, pas le Finder lui-même.

La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4

Olivier

10 réponses

1 2
Avatar
Gilles Aurejac
Olivier Marti wrote:
Bonjour,

Depuis quelques jours, je constate que le Finder prend en permance 60
à
100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
CPU de Menu Meter dans la barre de menu). Ce problème résiste à
plusieurs redémmarrages.

Ca ne me parait pas normal, mais je ne sais pas comment faire un
diagnostic plus précis et corriger ça.

Une idée ?



Tu as pas le calcul de taille de dossiers activé par défaut ?
Pas de connexion à un serveur, à un iDisk ?
Pas de candybar, de "haxies" unsanity, de partage de dossier avec
parallels ? Quels sont les éléments d'ouverture dans les préférences
système, rubrique comptes ?
Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
du dossiers "bibliothèque" du disque dur ?


Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
alors le processus mds prendre le CPU, pas le Finder lui-même.



Exact

La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4



Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
accès : recherche dans Google la procédure pour modifier le montage avec
l'option "no atime"
Avatar
olivier.marti
Gilles Aurejac wrote:

Olivier Marti wrote:
> Bonjour,
>
> Depuis quelques jours, je constate que le Finder prend en permance 60
> à
> 100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
> CPU de Menu Meter dans la barre de menu). Ce problème résiste à
> plusieurs redémmarrages.
>
> Ca ne me parait pas normal, mais je ne sais pas comment faire un
> diagnostic plus précis et corriger ça.
>
> Une idée ?

Tu as pas le calcul de taille de dossiers activé par défaut ?



Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
???

Pas de connexion à un serveur, à un iDisk ?
Pas de candybar, de "haxies" unsanity,



Non

de partage de dossier avec parallels ?



Avec Virtual Box. Mais ce dernier ne me sert quasiment jamais, il n'est
pas démarré.

Quels sont les éléments d'ouverture dans les préférences système, rubrique
comptes ?



iTunesHelper
LaunchBar
ClamXavsentry
MissingSyncMonitor
PopCHar
Weather Dock
Auto Mute
iController
Magic Pref
start-gpg-agent

et Radoshift Helper que j'avais essayé mais que je vais virer de ce pas.

Mais tout ces trucs apparaisent sous leur propre nom dans Moniteur
d'Activité.

Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
du dossiers "bibliothèque" du disque dur ?




~:ls /Library/LaunchAgents/
at.obdev.LittleSnitchNetworkMonitor.plist
com.machangout.glims.agent.plist
at.obdev.LittleSnitchUIAgent.plist
com.sourceforge.macgpg2.gpg-agent.plist
com.adobe.CS4ServiceManager.plist
net.culater.SIMBL.Agent.plist
com.google.keystone.agent.plist
org.freedesktop.dbus-session.plist@

~:ls /Library/StartupItems/
VirtualBox/
daemonic-dbus/

~:ls /Library/LaunchDaemons/
at.obdev.littlesnitchd.plist
com.adobe.versioncueCS4.plist
com.bombich.ccc.plist
com.bombich.ccc.scheduledtask.CF7ADB41-732E-4AE8-861A-6DC81490E6A3.plist
com.bresink.system.securityagent.plist
com.dilaroga.itaf_d.plist
com.eltima.ElmediaPlayer.daemon.plist*
com.google.keystone.daemon.plist
com.juicybinary.slntfsDaemon.plist
com.rogueamoeba.hermes.plist
org.freedesktop.dbus-system.plist@
org.macports.OpenSSH.plist@
org.macports.frameworks.macports.plist



> Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
> alors le processus mds prendre le CPU, pas le Finder lui-même.

Exact

> La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4

Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
accès : recherche dans Google la procédure pour modifier le montage avec
l'option "no atime"



On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.

Olivier
Avatar
gilles
Olivier Marti wrote:

> Tu as pas le calcul de taille de dossiers activé par défaut ?

Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
???



A mettre en corélation avec l'option "no atime".

un SSD peu lire des données par bloc, mais ne peut les écrire que par
pages. Autrement dit, on peut lire des données par paquets de 512
octets, mais chaque minuscule écriture oblige le SSD à lire la page
entière, et la réécrire toute avec le seule petit bloc modifié...

Ceci n'est pas génant dans la plupart des cas, mais MacOS X par défaut,
mémorise la date d'accès des fichiers (ce qu'on peut désactiver par
l'option noatime)
Avec les SSD ça ne fait pas bon ménage, car ça augmente terriblement le
nombres d'écritures et ralentit énormément le fonctionnement du SSD.

Je ne suis pas absolument certain de moi, mais je pense que dans une
certaine mesure le fait de demander au finder d'afficher la taille des
dossiers provoque aussi des réécritures de dernier temps d'accès...
choses qui sont à priori bien améliorées en activant le montage avec
"noatime"


com.adobe.CS4ServiceManager.plist
com.adobe.versioncueCS4.plist



tu t'en sers ?

com.dilaroga.itaf_d.plist



celui-ci semble causer des soucis avec Snow leopard d'après son auteur.
même si tu te sers d'itaf il faudrait supprimer ce plist.

> Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> accès : recherche dans Google la procédure pour modifier le montage avec
> l'option "no atime"

On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.



Ok super.

Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.



--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
Avatar
olivier.marti
Gilles Aurejac wrote:

Olivier Marti wrote:

> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
> ???

A mettre en corélation avec l'option "no atime".

un SSD peu lire des données par bloc, mais ne peut les écrire que par
pages. Autrement dit, on peut lire des données par paquets de 512
octets, mais chaque minuscule écriture oblige le SSD à lire la page
entière, et la réécrire toute avec le seule petit bloc modifié...

Ceci n'est pas génant dans la plupart des cas, mais MacOS X par défaut,
mémorise la date d'accès des fichiers (ce qu'on peut désactiver par
l'option noatime)
Avec les SSD ça ne fait pas bon ménage, car ça augmente terriblement le
nombres d'écritures et ralentit énormément le fonctionnement du SSD.

Je ne suis pas absolument certain de moi, mais je pense que dans une
certaine mesure le fait de demander au finder d'afficher la taille des
dossiers provoque aussi des réécritures de dernier temps d'accès...
choses qui sont à priori bien améliorées en activant le montage avec
"noatime"



OK. Mais je trouvais pratique de connaitre la date de dernier accès. Il
faut que j'y réfléchisse.



> com.adobe.CS4ServiceManager.plist
> com.adobe.versioncueCS4.plist

tu t'en sers ?



Non !

Mais dans une version précédente d'Adobe, j'avais voulu le supprimer, et
les applications Adobe n'arrétaient pas de râler. Il faut que je trouve
la façon propre de le faire.

> com.dilaroga.itaf_d.plist

celui-ci semble causer des soucis avec Snow leopard d'après son auteur.
même si tu te sers d'itaf il faudrait supprimer ce plist.



Oui, ITAF provoquait le réveil du Mac régulièrement. Pas possible de le
mettre en veille ... Je pensais avoir enlevé tous les morceaux.


> > Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> > accès : recherche dans Google la procédure pour modifier le montage avec
> > l'option "no atime"
>
> On verra plus tard. Pour l'instant le coup de la taille des dossiers à
> l'air efficace.

Ok super.

Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.



Oui, je vais faire des essais. D'autant que ça a l'air bon pour la durée
de vie du SSD.

Merci pour tout, et surtout tes très intéressants explications.

Olivier
Avatar
olivier.marti
Gilles Aurejac wrote:

Olivier Marti wrote:

> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça

Ok super.

Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.



J'ai trouvé les instructions complètes sur nullvision. Ca marche.

~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)

Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....

Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.

Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?

Olivier
Avatar
gilles
Olivier Marti wrote:

J'ai trouvé les instructions complètes sur nullvision. Ca marche.

~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)



c'est ok donc.

Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....

Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.



Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").

Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance, les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.


Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ? tu peux faire un chmod récursif (chmod -R 501:501 * dans
ton dossier utilisateur) pour vérifier... c'est bourrin !

Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder



Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?



En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)

cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html

Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...




--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
Avatar
gilles
Olivier Marti wrote:

J'ai trouvé les instructions complètes sur nullvision. Ca marche.

~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)



c'est ok donc.

Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....

Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.



Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").

Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance" cocher les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.


Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ?
Pour corriger, c'est un peu brutal mais tu peux faire un chmod récursif
dans ton dossier utilisateur :
chmod -R 501:501 *
(bien sûr, à supposer que 501 est bien l'uid de ton utilisateur)

Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder



Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?



En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)

cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html

Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...




--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
Avatar
olivier.marti
Gilles Aurejac wrote:

Olivier Marti wrote:

> J'ai trouvé les instructions complètes sur nullvision. Ca marche.
>
> ~:mount
> /dev/disk0s2 on / (hfs, local, journaled, noatime)

c'est ok donc.

> Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
> ouverte le CPU repart à fond ....
>
> Je vais suivre un peu ça pour voir comment ça se comporte sur le long
> terme.

Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").



Oui, j'ai cloné. Je vais donc nettoyer les caches. Mais après l'étape
suivante.


Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance" cocher les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.


Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ?
Pour corriger, c'est un peu brutal mais tu peux faire un chmod récursif
dans ton dossier utilisateur :
chmod -R 501:501 *
(bien sûr, à supposer que 501 est bien l'uid de ton utilisateur)



Tu veux parler de chown ?

J'ai une grosse 20aine de fichiers qui ne m'appartiennent pas.

~:find . ! -user marti -print
./Library/Application Support/Adobe/Acrobat/SpellingDictionary0.log
./Library/Application Support/Back-In-Time 2/Alias
./Library/Application Support/Back-In-Time 2/Alias/Alias désativés (à ne
pas monter)
./Library/Application Support/Back-In-Time 2/Alias/SparseBundle Disk
Image
./Library/Application Support/Back-In-Time 2/Alias/Time Machine Disk
./Library/Application Support/Back-In-Time 2/Back-In-Time History.txt
./Library/Application
Support/Firefox/Profiles/ui7e0hlq.default/cookies.txt
./Library/Application Support/Little Snitch/rules.xpl
./Library/Application
Support/OpenOffice.org/3/user/registry/data/org/openoffice/Office/Math.x
cu
./Library/Application Support/RealNetworks/RPDLAgentHelperE
./Library/Application Support/RealNetworks/RPDLAgentHelperI
./Library/Favorites/Documents
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/MacOS/BlueHarvest
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/Resources/clean-tar
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/Resources/count-tar-metadata
./Library/Preferences/.com.apple.dashboard.backup
./Library/Preferences/.com.apple.dock.backup
./Library/Preferences/.com.apple.finder.backup
./Library/Preferences/.com.apple.mail.backup
./Library/Preferences/.com.apple.Safari.backup
./Library/Preferences/.com.apple.Terminal.backup
./Library/Preferences/MacScan Statistics.plist
./Library/texmf/ls-R
./Pictures/iChat Icons
./Public/Logiciels/VPN/Apani Contivity VPN Client.url

La plupart appartiennent à root:marti.

Je viens de faire le chown, et le Finder turbine toujour ....

Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder



Je prend note, mais j'essaye le reste d'abord, car ça peut être un peu
fastidieux.

> Sinon il y a un mystère pour moi, dans la méthode proposée par
> nullvision : pour lire un fichier, il faut que le disque soit monté.
> Donc comment un fichier sur le disque peut-il affecter le montage du
> disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
> avant le redémarrage ?

En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)



Merci pour toutes ces infos.


cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html



J'avais lu ça il y a longtemps. Je vais jeter un ½il de nouveau.

Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...



OK.

Bon, je continue mes tests.

Merci mille fois de tes infos et de tes conseils.

Olivier
Avatar
olivier.marti
J'ai vidé les caches (systèmes comme utilisateurs). J'ai corrigé le
propriétaire des fichiers dans mon dossier utilisateur.

Le problème subsiste.

Clairement, c'est ~/Library qui est en cause. Mais si j'ouvre un par un
les dossiers qui sont dedans, le problème disparait. J'ai aussi enlevé
les fichiers qui sont dans ~/Library pour voir. En affichant les
fichiers cachés pour être sûr de mon coup. Pas mieux.

Donc le soucis est dans ~/Library, mais dans aucun de ses sous-dossiers
... ?????

Bon, rien de grave puisque je me passe très bien de la taille des
dossiers en général.

Mais c'est vraiment bizarre ...

Olivier
Avatar
gilles
Olivier Marti wrote:

J'ai vidé les caches (systèmes comme utilisateurs). J'ai corrigé le
propriétaire des fichiers dans mon dossier utilisateur.

Le problème subsiste.

Clairement, c'est ~/Library qui est en cause. Mais si j'ouvre un par un
les dossiers qui sont dedans, le problème disparait. J'ai aussi enlevé
les fichiers qui sont dans ~/Library pour voir. En affichant les
fichiers cachés pour être sûr de mon coup. Pas mieux.

Donc le soucis est dans ~/Library, mais dans aucun de ses sous-dossiers
... ?????



Etrange...
tu as donc supprimé les fichiers commençant par un point ?

Tu peux éventuellement créer un nouveau dossier "library", à la volée :
renommer le dossier library (mv Library Library_old) puis en recréer un
(mkdir Library), recopier immédiatement les dossiers venant de l'ancien
dossier Library, et rajouter juste le fichier ".localized" (touch
.localized, ça c'est juste esthetique pour que le dossier soit bien
affiché "bibliothèque" dans le finder).

désolé pour ton problème, mais il est intriguant :-)

j'espère que tu profites bien du SSD quand même !



--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
1 2