Estimated Transfer Time Is No More In Windows 8

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!"

Comments

Obligatory XKCD

[supersloshy]

You all knew it was coming ;)

Re:Obligatory XKCD

[idontgno]

This is Slashdot. Why would TFA have given anyone any idea about anything? That would have required reading it, and that never happens. Ever.

Re:Obligatory XKCD

[Moryath]

Not only that, it kicked my dog and stole my grandmother's false teeth!

Re:Obligatory XKCD

[GameboyRMH]

Yeah Microsoft can't fix a feature that works fine in most other OSes so they remove it entirely. Great work guys. Great work.

Re:Obligatory XKCD

[Sarten-X]

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.

Teracopy

[mehrotra.akash]

Perhaps they should just buy teracopy

Terrible summary & headline

[Godai]

First, I've never seen the progress bar in a Windows file transfer progress bar slide 'back and forth in a seemingly random, haphazard way'. I've seen progress bars that do that, and but I've never seen a Windows file transfer dialog do that. The estimation can jump around like crazy at times, but the progress bar was always fine (since, I assume, it's simply based on # of files completed). Maybe Windows 98 did that? I don't remember it doing that, but its been a while. Certain XP, Vista & Windows 7 don't.

Second, if you RTFA the estimated transfer time is currently still there; its just downplayed.

Re:Terrible summary & headline

[hcs_$reboot]

You read RTFA?

You read RRTFA?
Error Stack Overf%$3z/.$%#@

Windows really does that?

[Anon-Admin]

Wow, I guess I am out of touch with windows flaws. I quit running windows back at windows 3.1.

Ill stick with Linux until windows is ready for the desktop. ;P

Re:And The Rest Of What Makes Windows Garbage

[djdanlib]

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
(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:W7 is pretty good about it

[billcopc]

I think you meant to say "... performs better with larger files".

You nailed it though. My big gripe with Windows it how it seems to spend more time fiddling with metadata / directory entries than the actual contents. On an SSD with 700mb/sec writes and 0.1 msec access times, I'd expect it to churn through a few thousand files per second at the very least. That's not even factoring the disk cache. All those MFT updates seem to drag it right back down to spinning-disk speeds when dealing with numerous small files. You know, like a source tree or a directory full of images.

As sequential storage performance continues to improve, filesystem overhead is becoming the primary bottleneck.

What about search?

[CCarrot]

I'm still mad about the (basically) neutered search capability for desktop/LAN files in Windows 7.

What used to be a consistent
"right-click, choose 'Search', enter 'filename' OR 'phrase in file', tick off search parameters, optionally expand and enter detailed parameters, hit 'Search' button->Results"

workflow has been 'simplified' to

"enter your search string in this little text window and we'll search inside every goddamn file in this directory/subdirectory (oh, and across teh internets and rifling through your emails too, if you want!) for that search term, no matter how long it takes -> wait for freaking ever -> more results than you ever needed, or no results if it's a system file, not in an indexed location or Windows simply doesn't like it for some reason. Oh, you want additional search parameters? Good luck finding any besides filesize and date modified!"

You used to be able to re-enable old-style search on Vista (somewhat), but I guess they thought it was too much of a dinosaur (or too useful, perhaps) to include in Win 7. Bah. Get off my lawn!

Re:How about replacing an open file?

[Barefoot Monkey]

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.