Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why does Windows still place so much importance on filenames?

Why does Windows still place so much importance on filenames?

Rate This
  • Comments 35

Earlier today, Adrian Kingsley-Hughes posted a rant (his word, not mine) about the fact that Windows still relies on text filenames.

The title says it all really. Why is it that Windows still place so much importance on filenames.

Take the following example - sorting out digital snaps. These are usually automatically given daft filenames such as IMG00032.JPG at the time they are stored by the camera. In an ideal world you’d only ever have one IMG00032.JPG on your entire system, but the world is far from perfect. Your camera might decide to restart its numbering system, or you might have two cameras using the same naming format. What happens then?

I guess I’m confused.  I could see a *very* strong argument against Windows dependency on file extensions, but I’m totally mystified about why having filenames is such a problem.

At some level, Adrian’s absolutely right – it IS possible to have multiple files on the hard disk named “recipe.txt”.  And that’s bad.  But is it the fault of Windows for allowing multiple files to have colliding names? Or is it the fault of the user for choosing poor names?  Maybe it’s a bit of both.

What would a better system look like?  Well Adrian gives an example of what he’s like to see:

Why? Why is the filename the deciding factor? Why not something more unique? Something like a checksum? This way the operating system could decide is two files really are identical or not, and replace the file if it’s a copy, or create a copy if they are different. This would save time, and dramatically reduce the likelihood of data loss through overwriting.

But how would that system work?  What if we did just that.  Then you wouldn’t have two files named recipe.txt (which is good).

Unfortunately that solution introduces a new problem: You still have two files.  One named “2B1015DB-30CA-409E-9B07-234A209622B6” and the other named “5F5431E8-FF7C-45D4-9A2B-B30A9D9A791B”. It’s certainly true that those two files are uniquely named and you can always tell them apart.  But you’ve also lost a critical piece of information: the fact that they both contain recipes.

That’s the information that the filename conveys.  It’s human specific data that describes the contents of the file.  If we were to go with unique monikers, we’d lose that critical information.

But I don’t actually think that the dependency on filenames is really what’s annoying him.  It’s just a symptom of a different problem. 

Adrian’s rant is a perfect example of jumping to a solution without first understanding the problem.  And why it’s so hard for Windows UI designers to figure out how to solve customer problems – this example is a customer complaint that we remove filenames from Windows.  Obviously something happened to annoy Adrian that was related to filenames, but the question is: What?  He doesn’t describe the problem, but we can hazard a guess about what happened from his text:

Here’s an example. I might have two files in separate folders called recipe.txt, but one is a recipe for a pumpkin pie, and the other for apple pie. OK, it was dumb of me to give the files the same name, but it’s in situations like this that the OS should be helping me, not hindering me and making me pay for my stupidity. After all, Windows knows, without asking me, that the files, even if they are the same size and created at exactly the same time, are different. Why does Windows need to ask me what to do? Sure, it doesn’t solve all problems, but it’s a far better solution than clinging to the notion of filenames as being the best metric by which to judge whether files are identical or not.

The key information here is the question: “Why does Windows need to ask me what to do?”  My guess is that he had two “recipe.txt” files in different directories and copied a recipe.txt from one directory to the other.  When you do that, Windows presents you with the following dialog:

Windows Copy Dialog

My suspicion is that he’s annoyed because Windows is forcing him to make a choice about what to do when there’s a conflict.  The problem is that there’s no one answer that works for all users and all scenarios.    Even in my day-to-day work I’ve had reason to chose all three options, depending on what’s going on.  From the rant, it appears that Adrian would like it to chose “Copy, but keep both files” by default.  But what happens if you really *do* want to replace the old recipe.txt with a new version?  Maybe you edited the file offline on your laptop and you’re bringing the new copy back to your desktop machine.  Or maybe you’re copying a bunch of files from one drive to another (I do this regularly when I sync my music collection from home and work).  In that case, you want to ignore the existing copy of the file (or maybe you want to copy the file over to ensure that the metadata is in sync).

Windows can’t figure out what the right answer is here – so it prompts the user for advice about what to do.

Btw, Adrian’s answer to his rhetorical question is “the reason is legacy”.  Actually that’s not quite it.  The reason is that it’s filenames provide valuable information for the user that would be lost if we went away from them.

Next time I want to spend a bit of time brainstorming about ways to solve his problem (assuming that the problem I identified is the real problem – it might not be). 



PS: I’m also not sure why he picked on Windows here.  Every operating system I know of has similar dependencies on filenames.  I think that’s an another indication that he’s jumping on a solution without first describing the problem.

  • @dave: Really all that needs to be done is to ignore the underlying filename in the GUI, instead display names based on a combination of already-present metadata plus additional user-specified metadata (through the new GUI).

    See, it sounds to me like what Adrian is after (mostly) is simply a new front-end; that is, a replacement for or upgrade of Explorer. This "Pretty-Explorer" would display files using metadata, without regard to the underlying filename. A logical extension of how image files can be displayed as thumbnails, or how music files can be displayed as artist/track information instead of raw filenames. For example, with the new system, you might see a folder full of several text documents called "Untitled", with additional metadata - like the date - displayed in proximity (alongside, in a preview bar, something like that). The user doesn't care what the actual filesystem names are, since they operate on the documents.

    This still doesn't fully solve the issue of overwriting versus "side-by-side" copying. One could base the initial "guess" as to the type of copy operation solely on the new set of metadata - perhaps first switch on the specified "file type", using different logic for different files. If the metadata used in the check says the files are different, then they are copied side-by-side, with the underlying file system names being automatically modified, if necessary. On the other hand, if the metadata says the files are the same - perhaps they are both of type "Word Document" and both have the title "Apple Pie Recipe" - then the system would prompt the user as to whether they want the "old" file overwritten, or to simply have the "new" file exist side-by-side after the operation.

    This discussion really raises a lot of interesting UX questions. I feel that we are going down this road, but one must remember that there always also needs to be a way to represent the system as it "really is", for those times when either (a) you have a power-user who can work more efficiently with the "raw" view or (b) you need access to the system to aid in debugging, system recovery, etc.

    @Martin: What OS uses a filesystem that allows for non-unique fully-qualified filenames? (That is, the filename with absolute path, taking into account any case-sensitivity, etc.) I can't imagine how someting like that could even function, unless again the "filenames" you are seeing are not really filenames, but rather metadata displayed to the user when viewing from some front-end.

  • I think much of this discussion brings up SOME of the motivating reason for WinFS. I hope that gets resurrected some day.

    As far as the UX, I'd like to see Explorer (and every other program with the same pattern) keep track of "user-resolvable conflicts" as it continues to copy the remaining files that do not conflict. As it hits these conflicts, it should update a dialog containing a listView/dataGrid showing the comflicts, and allowing me to check a radio button of what to do for each, or for a multi-selection. That way, I would make these decisions as all the non-conflicting files continue to copy/move. Then, once I've made my decisions on each of these listed conflicts, I could hit "Apply". Additionally, the context menu for each file/conflict listed would allow me all the same verbs that an Explorer window allows.

    Just my two cents worth.

  • I think there should be tab in explorer that will display MD5 of a file and user can sort files having same MD5 and delete the duplicate ones.

  • I think there should be tab in explorer that will display MD5 of a file and user can sort files having same MD5 and delete the duplicate ones.

  • Maybe the solution for Adrian's real problem would be an explorer option that allows proper batch-renaming of files (then you could use the explorer sort order by date, or by album title or whatnot).

    NB: Windows Explorer _can_ batch-rename files, but only in a very limited way. And for more than ten files it breaks the name sort order (file(1).txt, file(10).txt, file(2).txt, ...).

Page 3 of 3 (35 items) 123