Submission details
[!] Windows hangs for a while when performing disk operations [!]
This is a severe low-level design problem. Applies to all of Windows and most software written for Windows. Vista made some progress with this, but still, it doesn't work as it should.
The problem:
Let's say you have a badly scratched CD (or even a good one, you'll still have to wait).
1. Put it in and close the tray.
2. Start "Computer"
3. You have to wait until the disk is finally read and initialized until you'll finally see all the icons and drives.
There are other examples of this. When you copy files from a crappy media, the whole explorer.exe process may hang for a while (so that includes your taskbar and desktop). Every file operation should be sandboxed (in separate process) so that when one operation has problems it doesn't stop other operations. That would also do good for problematic media and slow network connections. Another solution would be implementing asynchronous I/O (as chowmeined stated).
Here's a video for you to see what I mean:
http://www.youtube.com/watch?v=RaBfFNKvmXw
EDIT: Changed the topic name to something more meaningful.
Reimplement disk access.
Don't wait for one disk/network operation to complete in order to continue - multitask!
Asynchronous I/O is the answer here.
High
High
Not fixed
Discussion (11 comments)
Changed problem description.
Changed title from [No sandbox for local and network disk operation] to [No sandbox for local and network disk operations].
Thank's that finally someone posted this - this is somewhat annoying - I hate when the whole Explorer hangs just because of one of these operations mentioned.
Changed problem description.
This problem has existed for YEARS, and it is absolutely unacceptable.
Thank you, you're absolutely right.
Totally agree.
Changed title from [No sandbox for local and network disk operations] to [[!] Windows hangs for a while when performing disk operations [!]].
Changed problem description.
Changed solution description.
Changed problem description.
This functionality already exists.. it is called Asynchronous I/O. If you give some thought to it - it is absolutely impossible to change the API to make existing apps responsive when waiting for I/O if they do not use this async API.
But it is possible to make programs integrated into windows (like explorer) responsive. See the video and you'll get what I mean (=> show the contents and then WAIT for response, not the other way around)
This is really annoying! Why can't the disc info be cached until you open the drive or really access it with an app or the Explorer?
You should add that the Computer folder should save the drives view and refresh it while showing the old ones.
NIXin, don't write about sandboxing, because that's obviously the wrong approach and tells a bit about your technical knowledge.
But I agree - Explorer should/could be more responsive.
d_e: Why wrong approach? I know what sandboxing is. It's running something in a separated process that's completely unrelated to the parent. It doesn't have to run inside a virtual machine, just in a separated userspace so that won't interfere (in this case - won't freeze) with the parent or any other processes in the system.
Running an operation like that in a separated process might not be enough (it can still freeze a part of the base kernel, waiting for some information to continue) - that's why I proposed sandboxing that sort of operations.
Whatever it's called, NIXin is right.
NIXin wrote on November 2, 2008, 1:30pm
Changed problem description.