Red Hat Bugzilla – Bug 178872
gnome file dialog takes 30-40s to open /usr/bin after booting
Last modified: 2007-11-30 17:11:22 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): gnome-vfs2-2.13.4-4 How reproducible: Always. 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.
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+.
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.