Bug 178872

Summary:	gnome file dialog takes 30-40s to open /usr/bin after booting
Product:	[Fedora] Fedora	Reporter:	Benjamin LaHaise <bcrl>
Component:	gtk+	Assignee:	Matthias Clasen <mclasen>
Status:	CLOSED UPSTREAM	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-01-25 12:40:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Benjamin LaHaise 2006-01-25 03:04:09 UTC

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.

Comment 1 Alexander Larsson 2006-01-25 09:22:39 UTC

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 12:40:19 UTC

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.