Comment 2 for bug 133567

I've attached a backtrace of the command 'nautilus' run on the offending directory, but it doesn't look very useful. Nautilus doesn't crash, it just hangs for a long time (in the log, the delay starts after the lines 'Initializing gnome-mount extension; /bin/sh: /usr/bin/esd: not found' appear) . After that, it's fine. On subsequent accesses, it runs at normal speed.

In this instance, I'm mounting with the command:

sudo mount -t vfat /dev/sdf1 ATHENA

The mount command runs quickly. If I do

ls ATHENA

the listing comes up quickly.

But when I run "nautilus ATHENA" (whether I have run the 'ls ATHENA' command or not), the nautilus window appears, but there's a long delay before it is filled with the directory listing. During this delay, already open Nautilus windows don't respond, either, nothing launches from the Places menu, and nautilus doesn't launch from the command line. Then it all fires back into life after the delay is over (eg lots of Nautilus windows launch if I've tried to run them).

I have noticed that while Nautilus is frozen, either nautilus, gnome-volume-manager, or usb-storage tend to run at 4-7% of CPU, which is unusual.

This delay used to happen when I first installed Gutsy tribe 4, back in the days when gnome-volume-manager/gnome-mount could auto-mount the external drive (it can't anymore - see bug 132349). It would mount the drive, then when I first tried to access it through nautilus, I'd get this delay. I can't test it now because I can't get the removable drives to auto-mount anymore. :(

Some application versions I'm running are:

gnome-volume-manager 2.17.0-ubuntu1
gnome-mount 0.6.1-ubuntu2
nautilus 1:2.19.90-0ubuntu1
hal 0.5.9.1-ubuntu2

I've tried with both the 2.6.22-9 and 2.6.22-10 kernels.