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

Gel de Nautilus

12 réponses
Avatar
Cyrille
Bonjour,
Gel de Nautilus lorsque que j'acc=E8de un dossier particulier de mon disque=
(/ecole, en plus celui avec tous mes cours... :| )
Pas de probl=E8me si acc=E8s console ou acc=E8s via thunar. Ce dossier est =
racine sur une partition d=E9di=E9e. Si j'acc=E8de =E0 un sous-dossier de c=
e dossier via nautilus =E7a passe.
Avant =E7a passait sans probl=E8me.
Maintenant quand je clique, rien ne se passe... Gel de cette application un=
iquement. Si je force =E0 quitter, =E7a tue toutes mes ouvertures de Nautil=
us.

Quelqu'un a une id=E9e ? O=F9 sont les logs d'erreurs ?

D'avance merci, Cyrille

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

2 réponses

1 2
Avatar
Olivier Fournel
On Thu, Mar 05, 2009 at 12:18:36PM +0100, Cyrille wrote:
Bonjour,
Gel de Nautilus lorsque que j'accède un dossier particulier de mon disque (/ecole, en plus celui avec tous mes cours... :| )
Pas de problème si accès console ou accès via thunar. Ce dossier est racine sur une partition dédiée. Si j'accède à un sous-dossier de ce dossier via nautilus ça passe.
Avant ça passait sans problème.
Maintenant quand je clique, rien ne se passe... Gel de cette application uniquement. Si je force à quitter, ça tue toutes mes ouvertures de Nautilus.

Quelqu'un a une idée ? Où sont les logs d'erreurs ?

D'avance merci, Cyrille




J'ai déjà rencontré ce problème, et à l'époque, j'ai fait les observations
et conclusions suivantes : L'affichage était extrèmement lent losque j'accédais
à de grosses partition en FAT32. Il semblerai que celà serai du à
l'estimation de l'espace libre, qui marche différement avec une
partition FAT. Par exemple, la comande 'df' était également très longue.
Par contre, une fois l'estimation de l'espace libre faite par nautilus,
la navigation est normale dans la partition. Plusieurs solutions sont
possibles:
- corriger le bug dans nautilus, qui attent l'estimation de l'espace
libre avant de poursuivre: cette commande devrai être lancer en
'arrière plans'.
- lancer une commande 'df', qui permet ensuite à nautilus de marcher à
sa vitesse normale (ça marche, le noyaux doit se rappeller de l'appel
système)
- Ne plus utiliser de partition en FAT32.

Mes deux centimes,

Olivier

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
jeep_ml
>>>> "OF" <=> Olivier Fournel









Le(On) Sun, 8 Mar 2009 14:25:07 +0100,
Olivier Fournel écrivait(wrote) :

Bonsoir,

j'interviens ici, parceque je rencontre le même problème avec les
grosses partoches (~500Gio) en FAT32 ... mais *sans* Nautilus ! ;)

[...]
OF> J'ai déjà rencontré ce problème, et à l'époque, j'ai fait les
OF> observations et conclusions suivantes : L'affichage était
OF> extrèmement lent losque j'accédais à de grosses partition en
OF> FAT32. Il semblerai que celà serai du à l'estimation de
Pareil : ~ 15mn avant que mc puisse copier des fichiers, créer un
répertoire, ou répondre à une demande de descente d'arborescence.

OF> l'espace libre, qui marche différement avec une partition
OF> FAT. Par exemple, la comande 'df' était également tr~s
Ici aussi, ainsi que la commande 'di' cela ne semble pas lié aux
gestionnaires de fichiers mais plutôt au « parsing » [urf... c'est
quoi déjà l'équivalent fr ?] des dites partitions.

OF> longue. Par contre, une fois l'estimation de l'espace libre
OF> faite par nautilus, la navigation est normale dans la
Pareil ici, si je lance un 'df' ou un 'di' avant ou après une action
dans 'mc' (gestionnaire de fichiers en ncurses), 'mc' ne répond pas
avant que 'df' ou 'di' ait affiché les tailles => avant la fin du
« parsing » de la partoche.

OF> partition. Plusieurs solutions sont possibles:
OF> - corriger le bug dans nautilus, qui attent l'estimation de
OF> l'espace libre avant de poursuivre: cette commande devrai
OF> être lancer en 'arrière plans'.
Je ne pense pas que cela soit un bug, encore moins lié au
gestionnaire de fichiers quel qu'il soit.
En effet j'ai le mm problème avec *mc* et ceci que je lance ou pas
une commande df/di.
C'est juste que le système « parse » la totalité de la partition dès
qu'une requête se fait sur celle-ci (donc : soit une commande style
'df', soit un gestionnaire de fichiers, etc... soit tous ensemble !
;) ), enfin, c'est ce que j'en ai déduit.

OF> - lancer une commande 'df', qui permet ensuite à nautilus de
OF> marcher à sa vitesse normale (ça marche, le noyaux doit se
OF> rappeller de l'appel système)
Oui, je suppose qu'il met tout ça en mémoire, mais c'est long la
1ère fois.

OF> - Ne plus utiliser de partition en FAT32.
Ce me semble le plus à même de changer qq chose ! :)

Jeep.

--
Les femmes ont à leur disposition deux armes terribles, le fard et
les larmes. Heureusement pour les hommes, elles ne peuvent pas se
servir des deux en même temps.
-+- Marilyn Monroe -+-

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
1 2