Slashdot Mirror
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!"
Perhaps they should just buy teracopy
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.
Wood Shavings!
- Godai
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
This is Slashdot. Why would TFA have given anyone any idea about anything? That would have required reading it, and that never happens. Ever.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
-Billco, Fnarg.com
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.