File operations in Windows: the good and the bad, the past and the future

Microsoft’s Windows chief Steven Sinofksy has posted details of what file operations look like in Windows 8. There are a few changes, including a consolidated view of all current file operations that lets you pause and resume any of them. You can also click for more details and get a pretty graph.


Microsoft has also worked on the conflict resolution dialog, the one that says “Copy and Replace”, “Don’t copy”, and “Copy, but keep both files”. I consider this a pretty good dialog, but the new one adds the ability to inspect the actual files or even open them to check which is which.

A few observations. First, file operations are hard to get right from a usability perspective. I guess we have all had the experience of trying to help a non-technical user over the phone with some operation like, say, downloading a zip file, extracting it, and doing something with the contents. A common problem is that the user cannot find what they downloaded. Then they are not sure whether they did download it, and do so again. Then they get confused by the ZIP file, which mostly behaves like a folder in Explorer but is not quite the same; and of course since Windows XP SP2 all downloaded files are “blocked” by default which is another source of perplexity.

If you add complications like hidden folders and hidden file extensions in Windows Explorer, what should be a simple task can be really awkward. Let’s say your user has a video file called somemovie.vob that needs to be renamed to somevideo.mpg before it will play. With the default setting, when you rename it you actually get somevideo.mpg.vob. You have to talk the user through showing file extensions before it will work, or maybe open up a command prompt and use ren which does actually work correctly. Microsoft could fix this with a “Change file extension” option in Windows Explorer, but I do not know if this has made it to Windows 8.

The problems with hidden files and hidden file extensions show that something is wrong with the underlying model. Showing them is wrong because they are ugly and confusing; hiding them is wrong because you sometimes need them. It is a partial abstraction that is only partly successful. 

Apple’s solution in iOS is to hide the file system completely. The user will never have these problems. However, this is an autocratic approach that introduces new difficulties. If you have a documents in Pages in iOS you cannot move it directly to DropBox, for example, because there is no accessible file system. You are limited by whatever options the Pages app gives you for doing something with a document.

I believe thought that Apple is on the right lines. The app-centric view makes sense to users, and abstracting the file system so that users do not generally need to care about the location of a file is a reasonable goal. If the File Explorer goes the way of the command prompt, and becomes a tool used rarely by most users, that will mean Windows usability has improved.

Cloud-centric computing has potential to improve this, with your local storage just a cache of your internet-stored documents and data.

Finally, it is worth noting that file operations have got significantly better in Windows. Using the clipboard to copy and paste files, which I think came in with Windows 95, was a big advance. Then Vista fixed another annoyance: multiple file operations would abort on the first failure, leaving you uncertain which files had actually been transferred. Vista broke performance though, and file operations could be hilariously slow as Windows “discovered” files or just seemed to hang with a spinning bagel. Service packs and then Windows 7 pretty much fixed that.

I still like ROBOCOPY though. Hey Microsoft – why doesn’t Explorer have “Copy new and changed files only” or “Mirror directory”?

One thought on “File operations in Windows: the good and the bad, the past and the future”

  1. Don’t forget Hobocopy works brilliantly for doing backups with windows scheduler of files that are otherwise locked (it uses VSS)

Comments are closed.