 |
A project to make businesses more aware of their customer experience, and how to fix it. By Mark Hurst. |
| About Mark Hurst | Mark's Gel Conference | New York Times Story on This Is Broken | Newsletter: Subscribe | RSS Feed |
Search this site:
Categories:
- Advertising
- Current Affairs
- Customer Service
- Fixed
- Food and Drink
- Just for Fun
- Misc
- Not broken
- Place
- Product Design
- Signs
- Travel
- Web/Tech
Previous: Yahoo! automatic keyword tagging | Main | Next: San Francisco street name spelling
June 2, 2004 12:01 AM
Broken: Microsoft Windows file move
J Nelson Chadderdon writes:
This screenshot is from my Windows 2000 computer. I was copying a single file copy, which was around 5MB large, between 2 computers sitting 10 feet apart. Both computers were connected by ethernet to my local area network. Notice the status window reads, "1118478 Minutes Remaining."
There's an explanation from a Microsoft developer here: http://weblogs.asp.net/oldnewthing/archive/2004/01/06/47937.aspx
The answer given by the above MS developer link -
"I am going to count to 100, and you need to give continuous estimates as to when I will be done." They start out, "one, two, three..."
- doesn't make sense anymore when the file progress bar is almost totally finished (as pictured in the above image). There is only one file being transferred here.
Without wanting to start a Mac/PC debate, my Mac does a terrific job of estimating file transfer times. Yes, it may over-estimate at the very beginning of the transfer, but by the time that 1-2% of the transfer has completed, the estimated time is right on, and doesn't fluctuate very much at all.
This includes FTP, disk to disk, network and inter-partition transfers.
The Win2K time estimate is definitely broken.
This does not take the cake. I've seen estimates of over 20 years, albeit in a situation involving many files.
Not photoshopped. I've seen similar time estimates, while copying gigabytes worth of data. (But not while copying 5 MB, though.)
> If you were copying the file, why does the ?
> screen shot say "Moving..."?
Good observation David.
Ya, that raises doubt over the authencity of the original post. Now Original Poster what's u got to say to this :)
three comments:
1) bill and david may be on to something, but even if it wasn't authentic it wouldn't change the facts. We all know that the Windows deal is broken so it wouldn't be hard to find an authentic one similarly out of proportion.
2) When i read the first comment i thought it was funnier than the post:(Windows never has reported file copy time correctly, but that takes the cake.Posted by: Alden Bates)
and ...
3) What if it did take 1,118,478 minutes?
This is an original screen shot, uneditted. This screen shot was taken perhaps 2 or 3 years ago for my own amusement, before I knew of this web page. I very well may have been "moving" the file instead of "copying" it. Not this really maters, as when windows "moves" a file between file systems it needs to do a full file copy anyway. (Actually, this is standard for any file move on any plantform I've used, first copy it to the new location, then remove the original)
And, yes the fil;e did finish copying, in a tad less then the esitmated time :)
-nelson
(besides, read my original post, it is full of mistakes anyway.)
I also have such a screenshot with a different time, but also as high, for just a small file. It guessed the time quite correctly, but just in the last 98-100% it fucked up the time completely. If I remember correctly it somehow took it some minutes to simplete complete the move/copy.
I'm an avid 2K fan, and I have seen this happen several times when transferring files, so its not photoshopped. However, this happens to my machine when I am transferring gigs of data, not 5 megs.
Yeah. I've had this happen to me. And the posted 'explanation' from a Microsoft developer has nothing to do with it. Its purely and simply a bug. The file transfer will be going along nicely, with the estimate its normally inaccurate but vaguely plausible self. And then suddenly the estimate will jump to some ridiculous number (completely wrong if simply extrapolating the proportion complete to time taken so far ratio).
i've also had it estimate way too optimistically - i.e. steadily reduce the time remaining to zero despite the transfer being maybe a third complete. then when it gets to zero it jumps up to some insane number and just loses it. But I think that was only with an older version of Windows.
I wouldn't doubt this in the least, having seen the same thing multiple times. Usually happens when there's an issue with the network, so that the pace has slowed so much (really, stopped) that the computer really is estimating at 82 days (or whatever) at the "current rate". Give the OS credit for optimism, if nothing else, that it's actually going to be able to get the file copied, even if it does take that long! ;)
At some point, one could suggest that the OS could decide it's no longer reasonable to keep trying, and put up a "lost connection" or "unable to complete" message... and actually, it does, it just sometimes waits longer than a human might think is a point of no return. And to give props where due, the connection might be re-established yet (the OS hasn't yet decided that the connection is well-and-truly gone). The point is that the network stack still thinks there's a connection, so the estimate keeps getting updated.
The fix (if any) isn't in the estimation routines, it's in the way the connection is handled, and may be also be an aspect of the drivers for your network card, any network routers or switches, the quality of your network cabling, and other items that the poor OS can't control directly.
To be honest, why does anyone think this is a big deal? Sure it is annoying not to know exactly when an IO operation is going to finish, but it is not as though correct reporting was going to make it happen any faster. To that end, Yada's post makes the most sense. It isn't really the estimation routines you care about.
hehe...if it's going to take more than 60 minutes, it should display it in hours or days, or whatever. That's just hilarious. :-D
Yea, it is 777 days. Still, the estimates are a bit of at first in all the OS. I defragmented a 10gig hard drive, and WinXP told me to wait 27 hours. Actually, I think XP does do the min/hr/day converions. I'll have to check...
only 10 gig. Try 80. it took my computer 6 HR to defaragment when it stopped it still defragment alll the way.
P.S. i have a 1.5 GHZ CPU and an ATA 100 HD
Win XP HOME
When I had dial-up, I got this all the time. Although, it was true :). One it took 1 day to download some huge file. But it didnt take 8 years.
I find the handling of multiple files in a copy command to be the most annoying.
The way it seems to work is that Windows runs out and says 'Ok, I have to copy 100 files in 3 directories' and off it goes copying. It never takes the time to figgure out how big the total set of files are - and - of course - THIS is what needs to be figgured out in order to make the progress bar accurate.
So it goes off on its merry way copying the first file - lets say its 2gb. Now, as it copies that file - it thinks 'gee, this is a 2gb file and 1/100 so the rest of the files must be 2gb' and then uses that to figgure out its calculations. Then on to the second file that is 1k, and says 'Gee, the files must be (1k + 2gb)/2 each and I'm 2/100 so I have 1gbx98 files = 98gb to go. So in reality - its using number of files as its main basis for copy times.
If they would just ignore the number of files and count the actual bytes of data to transfer - we would all be a whole hell of alot better off.
Its like trying to gauge how long it will take you to get to your desination by the number of turns instead of the distance. "Gee, I must take 3 right turns to get to the store. I have made one right turn, I should be 1/3 of the way there and the remaning time is 2x the curent trip so far'.
Does anyone else see how stupid that is?
The file transfer rate isn't in the dialog, so maybe it was just a slow connection speed, i have also had file transfers with a speed of 1Kb/s (through msn messenger), so it may have nothing to do with windows itself, but with the connection
Augh, I know what you mean. I've seen this before in BitTorrent. I use it, and try to open a .TOR file. It comes up, connects over a half an hour, then shows the time to finish. (by the way, it's 1.1 GB of data.) It shows up as 14 minuter. "Reasonable" I think. Seconds later, it jumps to 3 hours. Well, what can you expect, it's 1.1 GB. Then, the %#@% thing jumps to 8 DAYS! This is when I was just gonna click the X. Then I realized, it might be funny to see how high it goes. So I watch. 14 minutes.... 3 hours.. 8 days.... 3 months... 1 year... 1 year 5 months... 3 years... And then a little infinity symbol shows up. I cracked up and exited. Never again shall I use BitTorrent. Thank you, trial version of WinRAR.
Comments on this entry are closed
Previous: Yahoo! automatic keyword tagging | Main | Next: San Francisco street name spelling
Windows never has reported file copy time correctly, but that takes the cake.
Posted by: Alden Bates at June 2, 2004 01:52 AM