The reason it happens that way is that the program says "write this data" and the linux kernel copies it into a memory buffer that is queued to go to disk, and then says "ok, done". So the program thinks it has copied everything. Then the program closes the file, but suddenly the kernel makes it wait while that buffer is pushed out to disk.
So, unfortunately the program can't tell you how long it will take to flush the buffer because it doesn't know.
If you want to try some power-user tricks, you can reduce the size of the buffer that Linux uses by setting the kernel parameter
vm.dirty_bytes to something like
15000000 (15 MB). This means the application can't get more than 15MB ahead of its actual progress. (You can change kernel parameters on the fly with
sudo sysctl vm.dirty_bytes=15000000 but making them stay across a reboot requires changing a config file like
/etc/sysctl.conf which might be specific to your distro.)
A side effect is that your computer might have lower data-writing throughput with this setting, but on the whole, I find it helpful to see that a program is running a long time while it writes lots of data vs. the confusion of having a program appear to be done with its job but the system lagging badly as the kernel does the actual work. Setting
dirty_bytes to a reasonably small value can also help prevent your system from becoming unresponsive when you're low on free memory and run a program that suddenly writes lots of data.
But, don't set it too small! I use 15MB as a rough estimate that the kernel can flush the buffer to a normal hard drive in 1/4 of a second or less. It keeps my system from feeling "laggy".