Bug 178872 - gnome file dialog takes 30-40s to open /usr/bin after booting
gnome file dialog takes 30-40s to open /usr/bin after booting
Product: Fedora
Classification: Fedora
Component: gtk+ (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-01-24 22:04 EST by Benjamin LaHaise
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-25 07:40:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Benjamin LaHaise 2006-01-24 22:04:09 EST
Description of problem:
When selecting an application to view a file in firefox, the gnome file dialog
takes 30-40s to display any contents of the directory listing of /usr/bin on
ext3 when the cache is cold.  In contrast, an ls after a fresh reboot takes
1-2s.  This is likely due to the fact that ls makes use of the file type
information returned in struct direntry64.d_type while the gnome file dialog box
performs a stat() on each individual file name.  Ideally the dialog box would
display results as they are fetched, which is to say that the names should be
displayed as they become available, and only after all the names in the
directory are loaded from disk should the stat() to determine file modification
time / permissions / size begin.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. reboot (or umount a filesystem with lots of entries in a directory)
2. attempt to use the file dialog box on a directory with many entries
3. wait while lots of disk access occurs
Actual results:
The time spent waiting is very long.

Expected results:
The time spent waiting is very short.

Additional info:
UI improvements are good.
Comment 1 Alexander Larsson 2006-01-25 04:22:39 EST
The reason is more likely to be that magic file sniffing is used to determine
the mimetype (for the icon, and for filtering) for files with no well known
extension (common in /usr/bin). Reassigning to gtk+.
Comment 2 Matthias Clasen 2006-01-25 07:40:19 EST
This activly being worked on upstream (in the kris-async branch), with the
goal of loading directories asynchronously, and display results incrementally.

THis is not going to be fixed in time for FC5, though.

Note You need to log in before you can comment on or make changes to this bug.