Would this method work for calculating time to copy file and is there a better way?

Question

4.00/5 (2 votes)

See more:

I am writing an application in C# and it copies a few files from one folder to another and I need a way to calculate the time remaining to copy it over and then display it in a progress bar. Would this work?:

Time how long it takes to copy 1 byte of the file and then {multiply that time by the number of bytes left to copy of the file. Add that total time to DateTime.Now to get the time in the future when it will theoretically be copied and convert it to a percentage and display it in the progress bar.} (repeating the section in curly braces for the number of bytes left to copy each time the copied byte count increases)

But this may not be good for small files which are what most of the files I am copying are and it may be overtaken by the actual copying of the file. Is this a good way to calculate the time left to copy a file and if not what else could I do? Thank you

Posted 9-Dec-13 5:25am

Henry Hunt

Add a Solution

3 solutions

Solution 1

The way I've done it in the past is to just do it by file. You can take the number of files to be copied and each time you complete a file recalculate how long it took and how long it will take for the remaining files.

If you want to do this by size, you would have to average out more than 1 byte of copying, then add some overhead to the time. For example you can measure the time it takes to copy 1Kb, then multiply that by the total number of Kb's to be copied, and add maybe 10% more time for file system overhead. You will want to recalculate the time required after every X kb's copied (for example, recalculate time after each 10kb).

There isn't a real accurate way to do this, even MS can't get it right (by anybody who's watched the time copying files in Explorer). You have to recalculate often.

Posted 9-Dec-13 5:29am

Ron Beyer

Comments

Sergey Alexandrovich Kryukov 9-Dec-13 11:39am

Agree, a 5. I also answered at the same time...
—SA

Solution 2

Files are written to disk in blocks (say 4K at a time), with automatic buffering. So writing a single byte tells you nothing.

I'd suggest that you benchmark full write of files of increasing size and do not use the progress bar on the files that take, say, shorter than 2/10th of a second. And for the others, update the progress bar in steps of that size.

Posted 9-Dec-13 5:35am

YvesDaoust

Updated 9-Dec-13 5:36am

v2

Comments

Sergey Alexandrovich Kryukov 9-Dec-13 11:39am

That's correct, a 5. However, I would advise to use just time and total size, copied vs total. As I tried to explain in my answer, in general case the time estimate will never be quite accurate...
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-12-09T05:37:00

Unfortunately, there is absolutely no way to predict the time of such operation with any reasonable accuracy. You can easily see this inaccuracy when you use some download manager of any Web browser showing percentage and expected time of completion. Often, expected time is oscillating back and forth back and force, changing seconds to hours and back. There are many reasons for that: traffic and operational environment changes, the chunks of data being downloaded change its typical size (say, long files are changed by a set of many very small ones), and so on.

When you copy files on the same machine, the situation is much more stable, but similar factors (except traffic) are still in play.

All you can do is to estimate remaining time by getting the time of already copies part and the percentage of already copied data. Not be surprised to see that the estimate is very inaccurate. I might feel some relief if you see how inaccurate is the estimate when you copy files with Explorer or any other file manager. There are multiple jokes about Microsoft in this regard; did you hear them?

For timing, it's always better to use System.Diagnostics.Stopwatch instead:
http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch%28v=vs.110%29.aspx[^].

—SA