User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux; X11; x86_64; pt, fr) KHTML/3.5.8 (like Gecko) (Debian) Build Identifier: When opening a directory in a big (>100GB) FAT32 directory with lots of files, Thunar is very slow to give the file list. I noticed in fact it is Linux that is slow on those disks : the command 'df' takes until 6 minutes on my USB1 system for a 250GB FAT32 USB external drive. But as konqueror is fast at opening such a drive, I think Thunar is doing something like df while only opening the directory. This should be done in a background thread to avoid locking the window. Reproducible: Always Steps to Reproduce: 1.Plug in a huge USB2 disk (huge means the command df is slow when first launched on it). 2.Open Thunar on any directory of this disk 2bis. Launch df command 3.As soon as df command finished, Thunar is responsive. Actual Results: Locked window for as long as 6 minutes! Expected Results: Do as Konqueror ;-) This bug can be reproduced at least on Mandriva 2008.0, Debian Sid x86 and x86_64
I've been looking around, and this seems to be caused by changes to the fat32 code since kernel 2.6.22. Apparently Windows no longer updates the 'blocks free' field in the file system properly, so the kernel has to scan the whole drive to be sure the free space is reported correctly. You can force the kernel to use the blocks free field in the filesystem by mounting with 'usefree' as a mount option; however, I don't know of an easy way to change the mount options used by exo-mount, and this would probably lead to the kernel reporting incorrect free space if the drive is used with a version of Windows that updates incorrectly. The scanning process will be optimised in kernel 2.6.24, I tested the newest kernel from git, and the time taken for df to run on a 160g drive went from about 3 min 30 sec, to about 4 sec.
Ok, I tested with the option on a 2.6.23 and mount time is OK. As I only write in the FAT32 disk under Linux, that's enough for me.