This is going to take a while
-
6.20 Gb at 3.99Mb/sec shouldn't take that long. I went to the kitchen for some food and came back some 15 minutes later and it was still like this.
-
this i have not seen. plz send teh codez
-
Sudden slow I/O screws up time estimates. Maybe "time remaining" updates every x seconds, while "speed" updates every y MB...?
...or maybe Windows's time_remaining=rand();, as I've always suspected. Seriously, whatever number it says is exactly how long the operation will NOT take.
-
@joemck said:
Sudden slow I/O screws up time estimates. Maybe "time remaining" updates every x seconds, while "speed" updates every y MB...?
...or maybe Windows's time_remaining=rand();, as I've always suspected. Seriously, whatever number it says is exactly how long the operation will NOT take.
I think it might calculate time for current file, then multiply it by number of files. These silly numbers seem to appear when copying a folder containing, say, a DVD image and lot of smaller files, then settle down once the big file has been copied.
The WTFs would appear to be:
1. Why do it that way when ( number_of_bytes / speed ) is the obvious, simpler, and more sensible method ?
2. AFAIK, it's been that way since at least W95, and possible 3.1.
-
[quote user="Renan "C#" Sousa"]
<snip screenshot>
6.20 Gb at 3.99Mb/sec shouldn't take that long. I went to the kitchen for some food and came back some 15 minutes later and it was still like this.
[/quote]
Out of curiosity, is this SP1? Or original flavour Vista?
I heard various perceptual file copy issues were meant to be fixed in SP1
-
@cheesemonkey said:
I heard various perceptual file copy issues were meant to be fixed in SP1
What they fixed in SP1 was ACTUAL perpetual file copying - where the system would slow down to copying a few bits every few minutes.
What this screenshot is of is a perfectly functionally fast copy with a buggered timer.
-
Hmmm... I wonder...
In .Net, the TimeSpan object is conspicously missing multiply and divide operators, which makes calculating things like average times and time remaining (time_so_far / percent_complete) * percent_remaining needlessly hard to do...
Maybe someone at Microsoft has some firm belief that timespans should never be multiplied or divided and has forced the shell team to come up with some time remaining algorithm that involves neither (and always gets the wrong answers)...
-
@mallard said:
In .Net, the TimeSpan object is conspicously missing multiply and divide operators, which makes calculating things like average times and time remaining (time_so_far / percent_complete) * percent_remaining needlessly hard to do...
Maybe someone at Microsoft has some firm belief that timespans should never be multiplied or divided and has forced the shell team to come up with some time remaining algorithm that involves neither (and always gets the wrong answers)...
What does one have to do with the other?
Do you think Vista is written in .NET? Why would .NET influence anything with the shell otherwise?
-
For me, most file copying operations on Vista (wth SP1) show nonsensical data - more often than not they'll say 'About 0 seconds remaining' for the whole time, even when I'm copying >10GB, and it insists that the speed is around 10KB/sec. The speed does change as the copy goes on, just to get smaller and smaller, to about 3KB/sec.
Looking at the properties of the destination folder, I can see that it's actually transferring at a few MB/sec, but I find it odd that the time remaining is unaffected by the tiny reported transfer rate.
-
@cheesemonkey said:
Out of curiosity, is this SP1? Or original flavour Vista?
I heard various perceptual file copy issues were meant to be fixed in SP1
Non-SP1.
@mallard said:
Hmmm... I wonder...
In .Net, the TimeSpan object is conspicously missing multiply and divide operators, which makes calculating things like average times and time remaining (time_so_far / percent_complete) * percent_remaining needlessly hard to do...
Maybe someone at Microsoft has some firm belief that timespans should never be multiplied or divided and has forced the shell team to come up with some time remaining algorithm that involves neither (and always gets the wrong answers)...
You could always do that to the total miliseconds of the TimeSpan instance you're dealing with, then generate a new TimeSpan with the results.
