When copying a large file to a USB disk (which is kinda slow) from my SSD (very fast), then the progress bar very quickly (in less than half a second) jumps to 200-250MB-ish. This happens because the kernel completes the write operations from user space and keeps the data on the way to the platters on disk in a cache.

Also, if the 'flush' FAT option is used on the target filesystem then, AFAICT, the file operations window is kept up until the cache is flushed. I believe this happens because close(2) blocks until all data has hit the platters.

So the user experience is really poor

 1. Start copying file

 2. Progress window pops up, progress bar is half full

 3. Progress bar is full

 4. Wait until data has hit the platters (many seconds)

 5. Done

Instead, it would be good to move the progress bar at a steady pace.

Here's an interesting write-up

 http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

In particular this bit "That causes the data to fill up memory, possibly forcing other useful code and data out" is interesting and I think we suffer from a similar problem. E.g. that the kernel may evict some useful pages in order to cache pages involved in the copy operation. Ideally we don't want any cache involved at all as

 - it's not going to help us anywhere in a copy operation; it's only
   going to consume resources

 - it may lead the user to believe that the device is safe to remove
   (unless the 'flush' mount option is used.. but this is only available
    for vfat)

Not sure this is easy to fix but I thought I'd file a bug anyway ;-)