Finder Consumes 90% CPU at file copy operation

I have also noticed that the Finder option "do not show icon previews" (found from View-Show View options) is not saving the defaults. i.e. - I unchecked the box, and clicked "Use as defaults" button. Then restarted my macbook. Now I discover that when browsing to some folders on the HDD Finder still has the icon preview option on! That might have been the issue, I am trying to verify now, since with that option enabled it is IMPOSSIBLE to copy huge amounts of image files - for the OS starts generating thumbnail previews for all of them, bringing CPU to 150% and almost hanging the finder. Thats an old bug and it has been described since 10.5.1 I guess.
I will report back on the results.

I have more info on the issue - apparently it has to do with file system on the external drive.
When the issue occurred it was formated as FAT32 for compatibility reasons (share with Windows box), I then reformatted as Mac OS extended (journaled) and voila! no problems with copy.
Then I verified by reformatting again as FAT32 - problem reappeared!
However that does not explain why most of the files copy fast and only some of them bring the issue.
Can anybody guess?

It appears that the issue was caused by one folder, containing 9700 images, with files size from 900 Kb to just over 10 kb. While copying this folder Finder invariably starts to consume large amounts of CPU time, and the copy speeds drops to below 1 Mb/sec.

I can not understand why, but even 130 files from that weird folder cause Finder to keep at 100% CPU while copying them. Those seem to be regular jpg files sized 900 kb each.
On the other hand, if I add all the 9700 files to zip archive, using OS built in archiver, which takes only couple of minutes, and then I can copy the whole lot in less than a minute!
Any ideas?

files are relatively small - from 100 kb to 3-5 Mb each, and the issue is - the slowdown occurs quite some time after the beginning of the file copy operation - for several minutes it goes OK, with Finder consuming only below 10% CPU, and copy speed 20Mb/sec. It is only AFTER SOME TIME that the issue starts to happen - and the files being copied are THE SAME TYPE FILES. and suddenly the speed drops to 1-2 Mb/sec, and CPU usage jumps up. The result - it takes ages to copy and overloads CPU.
So it must be a bug somewhere.
I cannot use Firewire, since the external drive is USB 2.0 which when it works as its supposed to (transfer speed 20-30 Mb/sec) is quite acceptable to me.
Surely I am trying to copy smaller batches of files - but that is a workaround, not a solution!

the problem is still there,
and I cannot understand the cause. In Activity monitor if I choose to Inspect the Finder process, it shows that the file access speed (open Files and Ports) is down - while at first it has up to three files opened for copy simultaneously, later, it opens only one at a time, and it takes couple of seconds! to copy a small 200 kb file! While this is going on the FInder is consuming 100% CPU.
OS is Leopard 10.5.7, fresh install of 10.5.5, updated to 10.5.6 via combo update. My system is otherwise 100% stable and shows no other anomalies.
Can anybody verify that this happens also on his mac - you need an external USB drive and a test copy operation involving at least 30 + thousand individual image files.

what's more interesting, I have bunches of similar folders with jpg files next to my weird one, and they copy no problem just like a breeze.
Can anyone point out as to where to look? I have checked and re-applied permissions of those files, which made no apparent difference.

hey, you don't need to tell me how to know the free disk space! =)
I have in excess of 200 Gb available out of 500 Gb HDD.
As you can read in my previous posts, I have narrowed down on just one folder, which caused the issue, but I can not tell how it it different from a bunch of others with similar files, sitting just next to it!

please read all my previous posts!

Files are not corrupted, they are perfectly straightforward jpg images, easily viewable in any viewer soft.