Can we talk for a minute about the Windows file copy dialog?

I had to rebuild some machines recently and watched in horror as the time spiraled up and down. It knows how long it takes to read and write files based on the first handful it reads and writes--how can the time change this much?

If you drill into the details a little and watch the files being copied, you will notice something odd--there is a major difference in the total time to complete the operation between when Windows is copying small files and when it is copying large files. Small files copy much slower than large files when you compare them in terms of bytes per second--this is because there is a fixed cost associates with copying a file, no matter its size.

Files need to be opened and closed, and the new file needs to be created; there is a lot of work behind the scenes going on. Of course it happens extemely quickly. But if you are moving thousands of small files, this time is pretty significant relative to the time to move the file contents.

So I propose that the author of the Windows file copy dialog make one small change (not related to one of my favorite XKCD jokes). The OS has already made a first pass through to determine how many files there are for the copy--why not, at that point, group the files into a few buckets by size, to better compute the overall time to copy? Or maybe take the fixed cost of the file copy operation into account when determining time to copy small files? What bothers me is not the time fluctuating so much--it is that I believe the author is simply comparing bytes copied per second to decide on how much time is remaining. This is going to vary wildly based on copying a single 1G file or 100,000 10k files. A little more work on the calculation algorithm would make the time so much more accurate!

OK, I am finished with my diatribe. Thanks for listening. But if someone knows who the developer is, please let me know so I can discuss with him or her!!!