How does Windows determine how long it takes to perform a given action on a file?

I wanted to know if there's an equation that Windows uses to determine how long it takes to perform an action on a file, say delete, to copy, to erase, or to install.

For example, when I'm deleting a file, and Windows says "Time remaining: 18 seconds" how is it calculating this number, and using what?

• As this number is frequently wrong, it is guessimate based on # files to delete, size, and speed the deletes are timed to increase or decrease the guessimate. Jul 16, 2014 at 3:39
• @Ramhound And how does it know how quick it takes? Is it the same static variable for all other machines, including ones running on SSDs, HDs? What if I have 200 GB of ram? What if I have 10 MB of RAM? How is it calculating how "quick" an action is? Jul 16, 2014 at 3:45
• @imreallyfamecore Well, the basic idea is that it measures how fast it's going for a few seconds, and assumes that the rest of the process will continue at the same speed, on average. If the average speed changes over time, it will adjust the estimate (leading to the infamous "Windows told me it will be copied in 10 minutes and it's already been 2 hours!"). It is just a guess, though - there's no way for the OS or any application to know how long it will really take. What if the HDD is corrupted? Or you're transferring over the network? Or there's lots of fragmentation? Jul 16, 2014 at 7:08
• I know I'll get punished for this, but I can't help myself. This is NOT your answer. XKCD: Estimation Jul 16, 2014 at 10:50
• The code: `timeLeft = random(1,100);` Jul 16, 2014 at 10:55

Have you noticed that usually it doesn't give you any estimates in the first seconds?

That's because in the first seconds, it just does the operation it has to do. Then, after a (small) while, it knows how much it already copied/deleted/etc, and how long it took. That gives you the average speed of the operation.

Then, divide the remaining bytes by the speed, and you have the time it will take to complete the operation.

This is elementary school maths. If you want to travel 360 km, and at the end of the first minute you travelled 1 km, how much will it take you to get to your destination?

Well, the speed is 1 km/minute. That's 60 km/h. 360 km divided by 60 km/h gives you 6 hours (or 360 km / 1 km/minute = 360 minutes = 6 hours). Since you've already travelled for one minute then the estimated time left is 5 hours and 59 minutes.

Substitute "travel" with "copy" and "km" with "bytes" and that's your question.

Different systems have different ways of estimating time. You can take the last minute, and the estimates may vary wildly, or you can take the full time, and if the speed actually changes permanently, your estimates may be far off reality. What I described is the simplest method.

• Just to clarify: Are you asserting that this is how Windows does it? Or are you merely illustrating some simple arithmetic by means of which an answer could be obtained? Jul 16, 2014 at 6:16
• and for the last `1%` it takes `time so far * rand[0 - 10]` while displaying `few seconds left`
– Mark
Jul 16, 2014 at 9:18
• If you are interested, this question tells you how Windows (and OSX) formats the time left into the progress bar once it has an idea on how long is remaining ux.stackexchange.com/q/23624 Jul 16, 2014 at 11:15
• I am not saying this is how Windows does it. If it does it exactly like this, it is a coincidence. It looks like it is, but this is a way by means of which an answer could be obtained. It looked to me that the poster wanted to know how this is done, and Windows was given as an example. A one-size-fits-all constant multiplied by the remaining size (as he proposed) is completely infeasible and I think it revealed that he had no clue how these estimations were made. Jul 16, 2014 at 11:18
• @ValmikyArquissandas: Raymond Chen (a developer on the Windows team at Microsoft) confirms this algorithm in a posting on his blog and and also explains why it can be wrong. blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx Jul 16, 2014 at 11:24

answering with a simple cross-multiplication is awfully condescending I think, I'm sure that he already knew that, it's how we constantly guesstimate things in our head too.

The problem with file-operation progress bars is that it's only correct for uniform data, so if you copy 100 files that have all the same size and your drive is doing nothing else, the estimated progress will be spot on, but what if the first 99 files were small txt-files and the last one is a large video file? The progress will be WAY off.

This problem is further increased when you're not handling files in one folder, but multiple sub folders. Say you have 5 subfolders and you want to delete them (size doesn't matter much in this case then), the first 4 folders only contain less then 10 files, so by the time the operation comes to the 5th folder it thinks it's about 80% done, and boom 5th folder contains 5000 files and your progress jumps back to 1%

WinXP tried to get around this by counting the number of files beforehand which meant that when the folder wasn't indexed in windows, depending on the number of files, XP didn't really start the operation for the first 20seconds (time it took to count) which made everybody furious.

So while I also don't have special knowledge on how Windows does it (but what else is there apart from counting files and bytes) I hope I could illustrate why it's flawed and why it never will be perfect.

Best you could do would be to not rely solely on filecount OR bytecount, but build an average out of the two.

Or if you wanted to go extra crazy the OS could start a database of how long these operations took in the past on your machine and factor that into the equation.

Final thought: If someone would think of a filesystem that would let the OS know what size every folder has, without calculating it first, you would at least get a correct progress estimation when deleting whole folders and not just parts of it.