Nautilus causes high cpu load

[bluehead]

Opening the location /usr/share/icons with nautilus results in high cpu load. The file manager does not respond for like 30 seconds until it displays the dir content.

nautilus-2.31.92-1

Can anyone confirm this behavior?

[RogerBacon]

Nautilus freeze for me when a directory contain a lot of file (sometimes it SEGV?).

[AdamW]

https://fedoraproject.org/wiki/Common_F14_bugs#nautilus_directory

[dd_wizard]

I had my fingers crossed when nautilus-2.32.0-1.fc14 appeared in koji, but no joy. :( Opening /usr/bin is as annoying as the man directory GoinEasy9 mentions in the bugzilla report.

dd_wizard

[GoinEasy9]

A picture is worth a thousand words....well maybe.

[flokip]

Working now ok fore me.
nautilus-2.32.0-1.fc14.x86_64

[dd_wizard]

Yay! I see in the bug report that glib2 needs to be updated as well as nautilus. That's why I still saw the problem with nautilus-2.32.0-1.fc14.x86_64. After updating to glib2-2.26.0-2.fc14, nautilus is fast again. :D

dd_wizard

[GoinEasy9]

New nautilus and glib2 came in last night, I made a comment on the bugzilla that all was now right with the world. Gimp errors, the "Save as" ones were also fixed last night. Let's see, my user name returned to the upper right hand panel, that's a good thing. I guess over the weekend I'll try to make a fresh install and put it through all the production machine paces.

[dd_wizard]

@GE9: Good luck with the install. With the recent updates and the 2.6.35.6-34 kernel, my test box is about as rock solid as it's ever been with any Fedora release. That's definitely a good sign. :D

Hrm, I just remembered...
$ installedpkgchk | wc -l
73

I still have quite a few packages compiled with the buggy gcc. That's an improvement from the 89 I used to have. Here's the script in case you want to check:
#!/bin/bash
# Last package I found that used gcc-4.5.1-1.fc14
# was 1284174516 QTeXEngine-0.2-4.20100119svn.fc14.
BUILDBEGIN=1284174516

# First package I found that used gcc-4.5.1-4.fc14
# was 1285565599 clementine-0.5.2-1.fc14.
BUILDEND=1285565599

repoquery --qf "%-50{sourcerpm} %{buildtime}" --installed --releasever=14 --whatrequires 'rtld(GNU_HASH)' | awk "\$2 > $BUILDBEGIN" | awk "\$2 < $BUILDEND" | cut -f 1 -d ' ' | sort | uniq | sed 's/\.src\.rpm$//'

dd_wizard

[GoinEasy9]

Thanks dd, that'll come in handy. Let's see how it works after the update I do when I get home tonight. At least just waiting for them to recompile apps is a lot different than the major fixes that have just gone by. I was starting to get worried, was thinking of skipping F14. <phew>

[Vector]

I can confirm that this does NOT only happen with large directories. I have this happen ALL the time with directories that have only ONE item in them (and i have a 6 core processor, so that's kinda sucky).

[RogerBacon]

I can confirm that this does NOT only happen with large directories. I have this happen ALL the time with directories that have only ONE item in them (and i have a 6 core processor, so that's kinda sucky).

Seems fixed w. 2.32