Why doesn’t the Windows Vista copy progress dialog show the names of the files being copied?, redux


As expected, everybody concluded that the Windows Vista copy progress dialog made every wrong decision possible. Let's look at some of the suggestions on making it suck less:

Why not update the file name every five seconds to the file that is being copied at that time?

Sure, you could do that, but the cost of getting the name is part of the problem. Retrieving the name is more than just "Remove everything after the last dot." You may have to look up localization information in order to display the name of the item in a manner appropriate for the user's preferred language. Since the operation being performed might be destructive (for example, delete or move), you need to retrieve the display name before you begin the operation. Since Microsoft Research hasn't yet finished their project to predict the future, we don't know at the time an operation starts whether it will take more than five seconds. Therefore, we have to play it safe and retrieve the name just in case. All you saved was the cost of the screen update; you didn't save the cost of retrieving the display names.

That said, in Windows 7, when you expand the file copy progress dialog, it updates the fields at a maximum speed of four times per second. This is probably a decent balance between not updating faster than the screen refresh rate while still updating fast enough that you don't get the impression that it's skipping some files.

Obviously the solution is to make getting localised names faster.

Yup, work was done to make getting localized names faster. When the copy engine begins operating on a directory, it caches all the localized names at one go and reads the names out of the cache as it processes the directory.

The reason 'updating the display is slow' is nonsense, as the progress bar is constantly updating anyway.

I think Drak didn't click through the discussion of how updating the screen can be a significant cost when you are updating continuously. The operative word here is continuously. If you're copying a lot of small files, and you redraw each time you get to a new file, you may end up redrawing hundreds of times a second. On the other hand, the progress bar updates only around ten times a second, and the copy rate only once a second, and neither have to access the disk to decide what to display next. A changing progress bar or updating copy estimate does not come across as unstable; they appear as progress. But a hundred file names flying past per second? That looks unstable.

Is it really necessary to display those names localized? Most users will never see them, and it'll confuse many of those that do see them.

Imagine if you clicked to delete the file Calculator.lnk and the dialog box said "Deleting 計算器.lnk". Would you be concerned?

It's only confusing if you sometimes see the nonlocalized names, like from programs which just assume that the display name can be obtained by deleting everything after the last dot instead of using the SHGetFileInfo function. But Apple has the same problem, and everybody knows that Apple does everything right.

It took me a while to realize that the complaint about disk-to-disk copy of several large files at once referred not to selecting multiple files and copying them in a single operation but rather starting one copy, then starting another copy, then starting another copy. If you copy them as a single operation, then they will queue up behind each other. But if you copy them as separate operations, then they will all compete with each other. The proposal to have a single queue for files copied to/from the same disk sounds interesting, but it quickly gets complicated:

  • Suppose there is a copy in progress from volume A to volume B, and another copy from volume B to volume C, and another copy from volume D to itself. Presumably, the second copy should wait behind the first (since they both involve volume B); should the third copy "jump the queue" and start immediately?
  • Is the queue implicit or explicit? In other words, is there a single dialog with a list box, one entry per queued-up operation? Or do you still keep separate dialog boxes, but just have the second dialog box wait until the first one is finished before it starts its operation? If you think about it, you can't have a single dialog with a list box: Suppose a program calls SHFileOperation, and its operation gets queued up. You disable the application window and do... what? Do you set focus to the queue dialog? That queue dialog is part of some other window hierarchy, so it can get stuck behind the caller's window. And even if you make sure it comes to the foreground (hooray for focus-stealing), you then have the problem that when the operation completes, focus goes to the queue dialog's owner, not to the program that triggered the focus change.
  • Suppose I start copying a large file from volume A to volume B, and then a colleague asks, "Hey, can you copy that shortcut to volume B so I can take a look at it?" Under the old system, you would start a second copy operation, and it would run concurrently with the first copy operation but complete first (since shortcuts are relatively small). With the queueing design, you would need a way to let people adjust the priority of jobs in the queue so the second one could be bumped ahead of the first. Which also means that when a partially-completed operation gets pushed down the queue, you need to be able to pause the operation and resume it later. This is a lot of UI to design, implement, and test, especially since we already decided that you can't have a single dialog box with a list box.
  • When the second operation queues up behind the first, its total estimated time needs to include the estimated times for all the jobs ahead of it in the queue. How do you get an estimate for a job that hasn't started yet? Do you do some preliminary calculations to come up with the estimate? But wait, that's going to access the hard drive and interfere with the first operation. Even if you have only one job ahead of you in the queue (and therefore have an estimate for that job), it means that copying a 1KB file might tell you "Estimated time to completion: 30 minutes" because it's waiting behind a 4GB file.

I'm not saying that these problems are unsolveable. But the simple suggestion of using a queue created a very large new problem. As we saw last time, you can't solve every problem; you have to decide which twenty problems you're going to solve and leave the others for next time.

Windows 7 decided to address the problem by letting you trade off performance for information. The operation defaults to performance (no file name updates), but you can expand the dialog to say, "I'm willing for my file operation to be a smidge slower in exchange for more information about how it's going."

I wonder if there are people would be willing to make the tradeoff "I'm willing to lose the progress bar in exchange for not having to wait for the operation to start while it calculates how big the progress bar should be." But I guess those people just use xcopy.

At any rate, the issue of the missing file names was fixed in Windows 7, so any further complaining just falls into the category of asking for a time machine. Though I did find it interesting that people suggested solutions that involved doing more work. Doing more work means writing more code, which means designing and testing more code, which means the product ships even later. I bet these are also the same people who complain that Windows always ships late. (What ever happened to the commenters who say that Microsoft should be deleting code more aggressively? Oh, wait, I know what happened to them. "Microsoft should be deleting code, but only the code for for features that I personally don't like." Good luck getting people to agree on what code to delete. It's like the people who argue that Microsoft should intentionally abandon backward compatibility, then change their tune when they realize that their favorite program stopped working.)

Comments (45)
  1. Marquess says:

    xcopy? You must mean Robocopy. Although neither seem to be designed for NTFS.

  2. SDL says:

    Considering RoboCopy has explicit support for NTFS Attributes, ACLs, Owner Info, Auditing Info, EFS, Symbolic Links and possibly other NTFS features, I can only assume you're incredibly ignorant or a troll. What does RoboCopy not support that it should that is specific to NTFS? I don't doubt that there may be NTFS features that RoboCopy lacks awareness of, but suggesting that it wasn't designed with NTFS in mind is clearly not true.

  3. Alexander Grigoriev says:

    "It took me a while to realize that the complaint about disk-to-disk copy of several large files at once referred not to selecting multiple files and copying them in a single operation but rather starting one copy, then starting another copy, then starting another copy. If you copy them as a single operation, then they will queue up behind each other"

    And you know what? You guessed wrong.

    Do a simple test. In Windows 7, start Resource Monitor (a quick way would be to click that button in Taskmgr Performance tab). Dump a few (5 or more) big ISO files (>500MB) or AVI files or whatever into one directory, select them all (or go up one level and select the directory) and do a copy to another drive. Watch per-process file IO stats in ResMon. You'll see that Explorer is reading them all at the same time. And the target files are also being written in parallel, in System process context (cache manager artifact).

  4. Dan Bugglin says:

    Interesting, I didn't know expanding the Windows 7 copy dialog actually made it do the extra work for the filenames.  Good to know I guess.

    A queuing feature would be useful for a future Windows.  I would suggest the following:

    • Queuing happen based on the disk that a volume resides in.  If volumes A and B share the same disk and C and D share a second disk, copies from A->C and B->D should result in the second one being queued.  This would work in the majority of cases, though would fail with some virtual disks IE TrueCrypt volumes which reside in physical files on another volume would not be detected as being part of the parent disk.  Perhaps an API could be created to change the physical disk that Windows treats a volume as belonging to for queuing purposes to work around this.

    • Based on the number of files, size of files, and past r/w performance of a drive (perhaps), Windows could make a rough guess at a completion time and decide whether or not to queue for that volume, or whether a copy is fast enough that it can be bumped to the top of the queue to quickly complete (your 1kb behind 4gb scenario).

    • A power user could manually pause copies (or use some other "defer until other copies on this volume complete" advanced button) to manually control the queue order.

  5. aaawww says:

    I wonder if there is a statistic on how much copy operation are completed with and without the extended information dialog open

  6. Masklinn says:

    Well I guess it's still SuperCopier for me, too bad it's still in beta for 64b systems. Yet it manages to be more stable than Explorer, as fast if not faster, and it does provide such features as queueing (and queues appending, removal and reordering), file-by-file names during transfer, much better estimates than Windows's own copy/move utility, pause/resume and a bunch of other stuff.

    [And more power to them. Remember that Explorer's copy engine operates on abstract storage, not on files. (It can copy files to/from ZIP archives, FTP sites, etc.) If you specialize to files, you can obviously do a better job than if you need to be general-purpose. -Raymond]
  7. Marquess says:

    “What does RoboCopy not support that it should that is specific to NTFS?”

    Hardlinks? Also, Junctions are lost, even those internal to the copied directory tree.

  8. James Bray says:

    > I wonder if there are people would be willing to make the tradeoff "I'm willing to lose the progress bar in exchange for not having to wait for the operation to start while it calculates how big the progress bar should be."

    Count me in.  I've had numerous occasions where the aforementioned calculation time far exceeds the actual copy time.  Granted, its mainly on removeable media, or when there are lots (tens of thousands) of items; but its still annoying.

    Still, like you say – its all about tradeoffs.  I'm sure if the progress bar was removed, you'd get plenty of complaints too :-)

    James

  9. SDL says:

    Marquess:

    I think Junctions are a bit of a dirty hack with Symlinks being preferable, but they only work on Vista or newer, so I can see their place.

    Hardlink awareness would definitely be very useful for a future version of RoboCopy, I have to agree with you there :)

  10. James Schend says:

    I feel that Dan and Masklinn kind of missed the point of the post. Raymond never said that the queuing problem was unsolvable, he said that solving it would mean a lot of work for Microsoft. (Including the associated QA time and overhead, and the potential delay of the product.) Additionally, more code always equals more bugs for people to complain about.

    If a third party company like SuperCopier wants to step in and take care of that work, more power to them. If you're happy with their product, then more power to you. But realize that that has nothing to do with whether Microsoft should add the feature to Explorer or not.

  11. Ari Kalish says:

    Off topic and maybe it's just me, but in IE and Firefox intra-page links to comments aren't working:

    blogs.msdn.com/…/10014185.aspx (first link in this post) brings up the post, but doesn't jump to the comment.  Probably a side-effect of the recent changes.

    [Yup, I even called it out on the "things that are still broken" page. -Raymond]
  12. Masklinn says:

    > And more power to them. Remember that Explorer's copy engine operates on abstract storage, not on files. (It can copy files to/from ZIP archives, FTP sites, etc.)

    While that is true, I don't think that's really relevant: the abstract backends could easily provide support for that kind of operations (any FTP client worth it salt has manipulable queues and support for suspend/resume for instance). Therefore I don't think it's a very good justification for the limitations of Explorer's file transfert. As far as I know, most of those limitations were there since the beginning, the file transfert stuff hasn't noticeably improved since the days of '95 (maybe earlier, but my recollections of this dialog become fuzzy)

    [The interface for the abstract backend was established in Windows 95 (IShellFolder). They were revised in Windows Vista with ITransferSource, but we all know how people feel about Windows Vista. So now all we have to do is update all the data backends in the system! (Good luck getting anybody to update WinINet.) -Raymond]
  13. Ari Kalish says:

    Oops…  thanks Raymond.

  14. Koro says:

    Actually, why have localized names at all? What's wrong with just… naming the file with the localized name it should have?

    All this dichotomy between "what the file is called" and "what desktop.ini says Explorer should call it" has been source of countless confusion to me in the past.

    As a bonus it would solve the "having to get the file's name" problem for the copy dialog.

    (Pre-emtpive reply: Yes, I know it may be related to backwards compatiblity, again. I'd like to know if there are other reasons)

  15. W says:

    @Koro

    The reason that localized filenames are implemented as is allows different users on the same machine to use different languages. This would not be possible with normal filenames. So MS actually has a good reason to do that.

    Still I strongly dislike the desktop.ini changes filenames. If I have ever seen a leaky abstraction, then this one. And IMO leaky abstractions are one of the worst things you can do.

    For example in WinXP some folders in "documents and settings" changed their name depending on which user you are logged in. ("My Files" vs "Files of <username>"). This really confused me.

    Or you can manage to get two files with the exact filename shown in explorer in the same directory.

    Now I'm using a filemanager which ignores those desktop.ini filenames. Still I'd like for an easy way to tell explorer to show the "truth".

  16. W says:

    @James Bray

    You have to be careful with measuring to prove that.

    It probably depends on which of the drives is limiting your copying speed. If it is the destination drive, you are probably right. If it is the source drive calculating the size first should not slow down the process much or might even be faster.

    To calculate the total size you need to enumerate the directory tree recursively. Once you have done that it is cached in RAM(either by the copying program or by the filesystem cache) which makes a second enumeration much faster.

    If you don't calculate the size first, you need to do that enumeration anyways, but this time you interleave it with the copying process. This should take at least as much time as if you had done it beforehand, but due to potential additional disk-seeks it might be even slightly slower.

    So you can't simply subtract the time the size-calculation takes from the total time to get the time copying would take without the size calculation. So you once again see that measuring performance is hard, especially in the presence of caches.

  17. Peter da Silva says:

    I agree with Koro. I didn't even understand what this: "Imagine if you clicked to delete the file Calculator.lnk and the dialog box said "Deleting 計算器.lnk". Would you be concerned?" referred to until I did some research… and I was basically horrified. If the file name is "Calculator.lnk" then why would it say "Deleting 計算器.lnk"? If the file name is "計算器.lnk" then why would I see it as "Calculator.lnk"? Changing the displayed names of objects is just plain evil.

  18. Alexandre Grigoriev says:

    @Koro,

    This is done to support highy hypothetical situation of multiple users on the same machine using different UI languages. Actually, this is how MUI works, and not necessarily for simultaneous different languages. Anyway, this discrepancy between display name and filesystem-exposed name has been there since I think XP, but perhaps not throughout the whole shell.

  19. arnshea says:

    BTW I loved the Windows Vista file copy dialog.  For small copies (in either number or size) the basic view (no throughput indicator) is just right.  For large copies I usually expand to advanced view but toss that up to subjective preference.

  20. Kelden says:

    > This is a lot of UI to design, implement, and test, …

    I cannot understand your complaints. If users would care about this we would still use DOS. Our customers don't care if a feature needs 10 lines of code or 10000.

    [Customers do care if a product is late or if some other feature got cut to make room for this one. -Raymond]
  21. Jared says:

    I only need the file name for error recovery.

    If windows/explorer is going to barf while copying a file, I want to know which file (and why).  Until there is a problem, I'll gladly give up watching file names.  But when there is a problem, I want the FULL name VISIBLE so I can know where to start fixing the problem.

    And the "cold stop" on error has always bothered me.  (Though each release gets better..)

    Out of space?  Suspend the operation wile I move some stuff around and then let's resume/retry at/with the failing file.  Target protected?  Ditto while I check the security settings.  Unexpected duplicate?  Ditto while I see what happened.  And so on…

  22. JJJ says:

    Regarding queueing, I think a context-menu item when you right-click and drag (in the same menu that says "Copy to", "Move to", etc.) that allows you to queue up the copy operation would work.  It offloads the algorithm intelligence to the user, is sufficiently discoverable by power users, and yet it's also hidden from users who generally wouldn't understand it.  Of course, I can say that because I copy everything with a right-click drag.

    To solve the other problems, I'd have a single queue, have each copy in its own window just like today, and not show estimations or progress at all for queued items.  The windows would just indicate that the copy is queued, perhaps with a button to unqueue it (and no, no putting it back once you've unqueued it).  It's OK if not everyone is satisfied with this solution.  If you can't satisfy everyone, at least you can satisfy me. ;)

    Plus, this feature would probably make a good intern project.

  23. hova says:

    I love how Raymond rips into all the ideas and criticisms surrounding the file copy dialog.   Unfortunately, the problem still remains that if I'm copying anything of serious size, the command prompt copy variants always provide 2x-5x speed increases.   Why?  I do not know, it simply is and has always been this way.  Changing the look of the dialog only makes it faster for trivial copies because it's easier to drag files than opening up cmd prompts and typing it out.  

  24. RotJ says:

    Slightly off topic, but what's the reason behind the drag and drop behavior when dragging files from a 3rd party program like 7-zip into an Explorer window?  Files are always copied to the %temp% directory first, and then copied from there to the intended destination.  This often severely increases the time it takes for the process to complete compared to using "extract" or "save to" commands in those programs, which bypass the %temp% directory. A few programs also use custom drag and drop routines to bypass Windows default behavior.

    [Because the people who wrote the third party programs don't read my blog. If all you have is a hammer (CF_HDROP), everything looks like a nail (file). -Raymond]
  25. Mihai says:

    One of the problems seems to be that users can't read  file names showing too fast.

    The obvious solution is to introduce a delay so that each file name show for at least one second ;-)

  26. Mordachai says:

    A queue would require a lot of "intelligence" on the part of the shell designer / explorer designer that I don't trust they have.  Don't go there.

    Start the copy before you know how long it will take or how much total there is – just adjust the progress bar as a 2nd thread does the enumeration (and only then if the details box is expanded).

    Fix fundamental issues before worrying about performance.  examples: (1) Give me a clear, easy-to-understand and manipulate interface for managing security settings on all of my shell objects.  (2) Create a scheme to allow an incomplete (failed) shell operation to be resumed (such as out of disk space on target – resume, cancel) instead of a "Error: blah-blah.  Press Ok (to NOT continue…)"

  27. Anonymous Coward says:

    Alexandre Grigoriev, at least on my computer IE saves them in the temporary internet files folder. Presumably this is because that's where the cache resides and there is no way to make files outside of that folder part of the cache. Either there is no way to get files from the internet while not using the cache, or IE's designers thought it was unsafe to leave an incomplete file already in place (which it is). I don't know if there are dangers to moving files out of the cache (which is shared between processes) but I do know that in some common cases moving is impossible (for example in the common configuration where the cache resides on C: but your documents on D:). But it does have an important downside: if you download a file and there is enough space at the target location, but not enough space for the cached file, you run into trouble. Either the download will fail, or the copy in which case you have to hunt for the file in the cache. (I haven't really used IE in ages though. The newer versions won't run decently and IE6… well…)

  28. Dale says:

    "What ever happened to the commenters who say that Microsoft should be deleting code more aggressively?"

    Right here!

    Get rid of all that code bloat due to application compatibility "fixes". Though, I get the feeling from reading "The Old New Thing" book, that Microsoft has started doing that by implementing application shims.

  29. Alexandre Grigoriev says:

    "Slightly off topic, but what's the reason behind the drag and drop behavior when dragging files from a 3rd party program like 7-zip into an Explorer window?"

    Even more offtopic, by why, when doing "Save target as", does Internet Explorer saves files into %TEMP% first, then _copies_ (instead of fast _move_) them into the target folder? That doesn't make sense at all. *Competing browser* doesn't do that.

    [Why not ask the IE folks? -Raymond]
  30. anonymuos says:

    Bullshit again. What % of performance is impacted anyways? Explorer displays the speed in MB/s too right? I don't see ANY drop in MB/s when I expand to show file names. May it has a hit of less than 0.5 MB/s?

  31. Someone says:

    @Alexandre Grigoriev>

    If you want to download a resource from the web then IE first checks if it's already in the cache and uses the HEAD http command to check if the resource has been modified on the server since you have downloaded it the last time. If not then IE can simple copy the file from the TIF to the destination without haveing to download the resource again.

  32. ender says:

    Imagine if you clicked to delete the file Calculator.lnk and the dialog box said "Deleting 計算器.lnk". Would you be concerned?

    I should have been clearer – I was specifically referring to the folders on C: (Program Files, Users, …), since those will be seen/used more often. Having one name in the list, and a different name in the textbox is really confusing. OTOH, I doubt that many people will care about the shortcuts (since those are usually pretty deep in the directory tree).

  33. James says:

    It seems kinda stupid to slow down copying for 99% of users for the extreme edge case where multiple users on the same machine use different languages. Wow, talk about missing the forest for the trees.

    Also, 100 file names a second doesn't look unstable, it looks *fast* (at the expense of the CPU required to redraw).

  34. Tom says:

    Man … people sure do have some opinions about a dialog.

    I don't even feel it's one of those small "spit and polish" things you can justifiably spend a lot of time on to make a good user experience into a great one.  I'd even go so far as to wager that 99.<some long string of 9's>% of Windows users have spent more time angry about calc.exe's scientific mode lacking [sqrt] than they've ever spent time thinking about the copy dialog.  

    Which is great, because when someone isn't thinking about it, it means it's working well for them.  

  35. Mart says:

    Regarding queues, I think it would be a nice feature to be able to drop files onto a file copy dialog to append files to the queue of that dialog. This would of course also set the destination folder of the dropped files to the destination folder of the copy dialog.

  36. scorpion007 says:

    @Tom, "Windows users have spent more time angry about calc.exe's scientific mode lacking [sqrt]"

    Huh? Calc has had a square root from day one: Inv + x^2.

  37. Alexander Grigoriev says:

    @Someone & Anon,

    From what I saw, Internet Explorer does NOT keep the downloaded file in the cache after it's done. The point of cache is to keep files that are fetched implicitly. WHen an user wants to save a file, why would he want to keep another copy of it around?

  38. Alexander Grigoriev says:

    @Someone & Anon,

    From what I saw, Internet Explorer does NOT keep the downloaded file in the cache after it's done. The point of cache is to keep files that are fetched implicitly. WHen an user wants to save a file, why would he want to keep another copy of it around?

  39. Wladimir Palant says:

    @Alexandre Grigoriev: The case that multiple languages are being used on the same machine isn't very theoretical any more, with Windows 7 it is pretty much reality. It will even happen that *the same user* switches between different user interface languages. On previous Windows versions already changing regional settings had horrible consequences. E.g. German "Zubehör" (Accessories) used to morph into "Zubehцr" with Russian regional settings and applications could no longer find it. While you might argue that this is all due to OEM charset which is an abomination anyway, I am really happy that in Windows 7 the file names are always the same – no matter what user interface language you use. It is only the displayed name that changes. Leaky or not, this abstraction made many things a lot simpler. And I no longer need to be afraid that switching to Georgian regional settings (which I do for testing occasionally) will mess up my system horribly. Thanks, I can live with file name display being slightly slower.

  40. ac says:

    A much more pressing matter than this is figuring out what each click of Undo does since it doesn't seem to show what it does anywhere. eg. You do a bunch of file operations, then realize you may have done a mistake, it would be nice to see what the undo will do.

    Another issue is that Undo doesn't often undo things back to exactly as they were, for example if files were moved between two internal partitions it should be able to set the dates back as they were after undoing.

  41. ac says:

    Why does not the Move file progress dialog in Windows 7 show the names or even speed of the files being moved?

    You can try this:

    Mount a 2nd HDD under say C:mountpoints2NDHDDMOUNTPOINT using diskmgmt.msc

    Then move large files that would take say a minute to copy between from one hdd to next from say c:here to under the mounted volume of 2nd HDD.

    No file names or speed is displayed.

    Also:

    No free space or total size is shown for the mounted volumes in the view that comes when pressing Windows+E (explorer) like is shown for volumes with drive letter and network shares with drive letters.

    Also:

    Why am I mounting the HDDs in inconvenient place instead of through Drive Letters? Well for some reason, the caching system doesn't properly cache information from QueryWhateverDriveInformation API (forget the name), and when the 2nd HDD is sleeping, it is woken up by for example Visual Studio that wants to know the size of all physical HDD's. Even though that information cannot change while the drive is sleeping! Seriously annoying design. If you ask me, if I got 8 GB of memory and 7 GB usually free, the whole MFT,Index and all root files of sleeping HDDs should be cached up just before it goes to sleep.

  42. ac says:

    correction: The QueryVolumeWhatever still wakes up drives even when they're mounted behind the mountpoints, however some 3rd party apps just go through all drive letters rather than all volumes so it does seem to help sometimes in avoiding unnecessary wake ups when apps just want to know some basic drive information that could be cached before sleep at practically no cost. And Visual Studio isn't truely the culprit, the Customer Experience Improvement feature is.

    In other annoying news, the defrag/indexing service goes off when computer is not idle (any Human input device such as USB MIDI dongle activity counts should count as Not Idle). Also the WEI benchmark is configured to run regardless if there is say a game running after the 24 hour elapsed from display driver update after when it was first supposed to run. I've also seen something cause freezes exactly X (20?) minutes into watching a video file with WMP. I suspect it's some service waking up the sleeping HDD's.

  43. Samantha says:

    I'd say that windows should just run a few test benchmarks copying between different volumes in order to get some ideas on performance or different operations, not just a single copy from A to B but also if parallel copies from A to B and C to D or C to B can run at an acceptable performance (for instance if B was SSD) once it had it's numbers, it can make a quick estimate based on the file size, I would have the queue / gueue jumping / parallel copying / pausing one operation to complete another first, customisable but i'd say a good setting would be, that it will allow another operation to either run in parallel or complete first, if it doesn't increase the time it will take by more than 10%. you can also just have a 'faster' button on the dialogue box, which then gives that operation priority (easier than clicking 'pause' on 5 other boxes)

    solution for the dialogue boxes, is have both, when a program calls a copy operation and it gets a box, then it displays it as it should, when a second simultaneous operation starts, the original boxes stay with their parent windows, but the entry in the task bar is replaced with a single "multiple file operations" window that when displayed, pauses or greys out the individual boxes (if their parent windows were still visible) and itself contains a queue, showing the multiple operations, with the ability to pause them, or start others in parallel shift them up and down the queue etc. (perhaps in an advanced mode). greying out the individual dialog boxes will prevent the user from thinking there are extra copies happening than there really are, and it won't cost extra in resources, but leaving them existing means that they're still valid if the program that started the operation grabs focus back or the user alt-tabs or whatever.

  44. Samantha says:

    I'd say that windows should just run a few test benchmarks copying between different volumes in order to get some ideas on performance or different operations, not just a single copy from A to B but also if parallel copies from A to B and C to D or C to B can run at an acceptable performance (for instance if B was SSD) once it had it's numbers, it can make a quick estimate based on the file size, I would have the queue / gueue jumping / parallel copying / pausing one operation to complete another first, customisable but i'd say a good setting would be, that it will allow another operation to either run in parallel or complete first, if it doesn't increase the time it will take by more than 10%. you can also just have a 'faster' button on the dialogue box, which then gives that operation priority (easier than clicking 'pause' on 5 other boxes)

    solution for the dialogue boxes, is have both, when a program calls a copy operation and it gets a box, then it displays it as it should, when a second simultaneous operation starts, the original boxes stay with their parent windows, but the entry in the task bar is replaced with a single "multiple file operations" window that when displayed, pauses or greys out the individual boxes (if their parent windows were still visible) and itself contains a queue, showing the multiple operations, with the ability to pause them, or start others in parallel shift them up and down the queue etc. (perhaps in an advanced mode). greying out the individual dialog boxes will prevent the user from thinking there are extra copies happening than there really are, and it won't cost extra in resources, but leaving them existing means that they're still valid if the program that started the operation grabs focus back or the user alt-tabs or whatever.

  45. Samantha says:

    You know what, I think there's a fairly elegant, simple soultion that works at least until there's more than a handful of operations at the same time. If the performance drop off that happens with multiple symultaneous copies is due to disk seek times, then simply make it so that the round robin between which item is hitting the disk is set to something like 1MB, so that any file under 1 meg will wait it's turn in the queue and then in a second or two will copy entirely and be done, with 3 files 100mb each, then each one would copy 1MB in turn until they're done. This will massively reduce the number of seeks the disk has to make while doing multiple symultaneous copies, while still allowing suitable fast response when trying to do a very small operation while a large one is already being carried out.

    for more than a handful of files at the same time, then a queue could still be useful in which case i'd say the manual queue using the right click dialog as suggested above, would work great.

Comments are closed.

Skip to main content