File managers, parallel copy, and performance hits
Scenario: I’m using an everyday modern GUI file manager to copy a huge file to my portable harddrive. A few minutes later, while the first transfer is still in progress, I realize that there were actually two huge files I want to copy to my portable harddrive. What are my options? I could copy the other file right away, or I can babysit the file copy and copy the second file when the first one is complete. The disadvantage to the first option is that the files copy in parallel. Harddrives operate best when used sequentially. Copying the files in parallel reduces the total rate at which data is copied to the harddrive, thanks to the head having to jump around to different parts of the disk. The total time of the operation is significantly increased. The disadvantage to the second option is that I have to sit here and babysit a process that should be automatic. I’m just copying two files. What if my two files would take 15 minutes each to copy, but I want to do something that is going to take half an hour, and then come back and collect my portable harddrive and then leave immediately? Another similar scenario: I want to copy two huge files to the same destination, but they’re in different source directories, meaning I can’t select both of them at once. The solution? I think a queue would work nicely, but while solving one problem would introduce several others:
- User confusion: “why aren’t my files copying [right away]?”
- Having to add a complex UI to otherwise simple and unintrusive file-copy dialogs to handle queues - at the very least, you need to be able to remove the items from a queue
- Priority/detection of when queues should be used; should queues always be used when the destination device is the same for every file? Should queuing be explicit [Copy -> Paste (add to queue)]? Or maybe it is parallel that should be explicit [Copy->Paste Immediately]?
