Estimated Transfer Time Is No More In Windows 8 456
MrSeb writes "Ahh, the Windows Explorer progress dialog. For years it has been struggling to figure out how to calculate how long our copy and delete operations would take, sliding the progress bar back and forth in a seemingly random, haphazard way, the laws of time all but ceasing to exist — five seconds remaining one moment and 13 minutes the next. That's (almost) all going to change, with the arrival of a greatly improved file management experience in Windows 8. Copy, move, delete, rename, and conflict resolution are all being overhauled and it's about time!"
Re:And The Rest Of What Makes Windows Garbage (Score:4, Informative)
Oh, kids these days just don't troll like they used to. How about we get some facts in here, instead?
There is no standard directory separator:
/ is UNIX and derivative OSes since the beginning of subdirectories
: was the separator on MacOS from the 1980s until MacOS/X
\ is DOS and Windows, from the 1980s
VMS was this massive mess: http://www.itec.suny.edu/scsys/vms/ovmsdoc073/V73/6489/6489pro_010.html [suny.edu]
(Were there others?)
Also, if you lose your Registry... wow. Never seen that happen in 16 years of working in IT. I think the last time I heard of that was when someone's hard drive started going bad, and they were running Windows 95, and had never backed up anything in their lives. Why wouldn't anyone back up their hard drive regularly, anyway? Some people must like the pain of reinstalling everything and starting from scratch... Mac / UN*X users are not exempt from this requirement either.
Re:How about replacing an open file? (Score:5, Informative)
And exactly which OS(es) allows you to rename or move files that have write exclusive locks on them? Because, from what I can see this has, again, nothing to do with Windows.
BSD, Linux and MacOS allow you to do that, and even delete or overwrite the file while it's still locked without causing problems. Moving, deleting or renaming a file affects only a hardlink to the file and not the file itself; and overwriting a file is actually just deleting a hardlink and writing to a completely new file.
Re:Obligatory XKCD (Score:4, Informative)
So how do you calculate how long it will take to copy files?
Off the top of my head:
Maintain a table of expected speeds for each storage device on the filesystem. Record how long it takes to read the filesystem information. When a device is mounted, if it's reasonable for the device type, seek to the middle and end, measuring speeds there, too. Get approximate curves for the read and write speeds across locations, and use those for future estimates. For future read and write operations, take note of where they are and how fast they go, and adjust the curves accordingly.
When an operation starts, look at the curves for input and output for the respective devices. Find the expected speed for the target location. Whichever speed is lower should be used for the estimate.
With so many conditions and edge cases and minutia, simply projecting estimates from sampled speed data seems like a pretty good compromise if you want an estimate of the time.
Edge cases are edge cases, and shouldn't be causing incorrect estimates most of the time. Estimating based on the first few seconds of an operation makes sense if that's all the information you have, but a modern operating system should be able to know so much more than that now. It should be able to know the effects of virus scanners and verification. It should know how fast a device has performed in the past.
Problem is, people don't understand it's an estimate.
Saying that your transfer will take somewhere between 5 minutes and 9 hours is not an estimate. It's a mockery. What I want to know is whether I should get a cup of coffee, watch some TV, or read a novel. What I'm told is that my OS has no idea what it's working with.