You can filter the Common File dialog with wildcards


A customer reported an apparent inconsistency in the shell common file dialogs:

The question mark appears to be treated differently from other invalid file name characters. I tried to save a file in Paint under the name ?.jpg but instead of telling me that I had an invalid character in the file name (as it does with other characters like / < and |) or navigating to a new folder (like \ or *), it appears to do nothing.

Actually, it did do something. You just couldn't tell because the result of that something was the same as doing nothing.

If you type a wildcard like ? or * into a common file dialog, the dialog interprets this as a request to filter the list of files to those which match the wildcard you specify. In this particular example, typing ?.jpg says "Show me all the single-character files with the .jpg extension." From the description in the original report, I gather that the customer's tests took place in an empty directory (so the filter had no effect).

The customer responded with muted surprise.

Hmmmmm.....interesting. I hadn't realized you can type in your own filter in dialog boxes. How long has this feature existed?

The ability to filter the common file dialog has been around since the dialogs were introduced in Windows 3.1.

Comments (46)
  1. Ian Boyd says:

    i use the feature regularly, and have for many years. i didn't know it went back to Windows 3.1, which i used for a year before Windows NT 3.1.

  2. Sam says:

    I often use this feature and hadn't realized it was relatively unknown.

    One of my biggest frustrations with Office 97 was that since they did their own custom open dialogs, sometimes this feature wasn't working properly.  In particular I often had to use Access 97 to open files with a nonstandard extension (.ebp) and entering *.ebp in the Access 97 file open dialog gave me an error messagebox instead of filtering, while apps that used the normal common dialog handled it correctly.  (It may have been a weird configuration on my system, because I can't reproduce it on my new one; but if they had used common dialogs, it would have just worked.)

  3. Adam Rosenfield says:

    I just discovered that in Windows 7 (not sure if this applies to earlier versions of Windows or not), you can type U+F03F into the Common File dialog (or Explorer) to get a literal question mark in a filename, although it's displayed as middle dot (·, U+00B7).  U+F03F is a Private Use Area character (note that U+003F is the standard question mark).

    I found this out by using Cygwin to create a file with a question mark in it and then seeing how Explorer et al handled it.  Good job to the Explorer folks, since this seems like a very sane solution — using PUA characters for filename characters that have special meaning in Explorer but are otherwise perfectly legal in NTFS.

  4. dalek says:

    I can imagine someone that never had any experience using a command line interface not knowing about wildcards at all. I can't imagine someone not getting someone with a little bit more computer experience to  explain certain behavior of computers/software. Or searching the internet. Anyway (according to the description of the conversation) the customer knew that the question mark is an invalid character, and still tried to use it for a filename. Which led to unexpected behavior……. I sure hope this customer wasn't a developer.

  5. Dan Bugglin says:

    U+F03F is not the same character as U+003F so it is valid.  It's as simple as that.

  6. Dan Bugglin says:

    U+F03F is not the same character as U+003F so it is valid.  It's as simple as that.

  7. Adam Rosenfield says:

    @Dan Bugglin: I didn't say it was invalid.  I was merely observing an interesting side effect: if you type U+F03F, it's displayed as a middle dot, but when you actually save it to disk, it's stored as U+003F in NTFS.  You can verify this by writing a short program that calls CreateFileW() with the raw filename containing U+003F in it.

  8. Dan Bugglin says:

    Interesting.  Can you manipulate the file from Explorer and other apps, or do they try to name it using a normal question mark and thus fail to open it?  If you can't delete the file normally it seems like the sort of thing malware would abuse, so I wouldn't rely on Microsoft not removing this behavior in a security patch down the line.

  9. Random832 says:

    That's actually just how cygwin handles filenames with 'illegal' characters – even though NTFS supports question marks cygwin overlays the win32 api which blocks them at that level.

  10. Random832 says:

    [sorry for double posting] I couldn't duplicate your result with a test program – CreateFileW just gives ERROR_INVALID_NAME. Cygwin reference here: http://www.cygwin.com/…/using-specialnames.html

  11. Adam Rosenfield says:

    Yep, I can still manipulate it with Explorer and other apps.  It's treated just like any other weird character — you wouldn't even know that it's not a middle dot unless you started enumerating the directory contents yourself with FindFirstFileW/FindNextFileW.  Firefox displays it with a placeholder box character (a box with F03F written in the corners), but as far as I can tell no programs have any problems reading, writing, renaming, or deleting such files.

  12. rsola says:

    A thing that puzzles me a bit is the apparently inconsistent behavior regarding some wildcard patterns in the common file dialogs and in other APIs like FindFirstFile or programs like the Windows command-line interpreter (Cmd.exe). I know those subtleties were present at least on Windows 95 and Windows NT 4.0 by means of the "new Windows shell". Some older versions of Windows NT may have supported long filenames before Windows 95 was released, perhaps starting at Windows NT 3.5, I don't know for sure because I can't test them.

    A simple example of extraneous pattern is "*.". Depending on how and where it is used, it might mean "all filenames with no extension" (the old DOS way) or "all filenames ending with a dot", which is illegal in the Windows API (so it wouldn't normally return any filename), but possible at the NT API level and the POSIX subsystem.

  13. rsola says:

    A thing that puzzles me a bit is the apparently inconsistent behavior regarding some wildcard patterns in the common file dialogs and in other APIs like FindFirstFile or programs like the Windows command-line interpreter (Cmd.exe). I know those subtleties were present at least on Windows 95 and Windows NT 4.0 by means of the "new Windows shell". Some older versions of Windows NT may have supported long filenames before Windows 95 was released, perhaps starting at Windows NT 3.5, I don't know for sure because I can't test them.

    A simple example of extraneous pattern is "*.". Depending on how and where it is used, it might mean "all filenames with no extension" (the old DOS way) or "all filenames ending with a dot", which is illegal in the Windows API (so it wouldn't normally return any filename), but possible at the NT API level and the POSIX subsystem.

  14. rsola says:

    Sorry for the duplication. Sometimes I don't know if the comment was accepted.

  15. Emtucifor says:

    It's funny that people don't know this. I use it all the time, mostly to navigate to a desired path through the keyboard. You can also use "move up one directory" which is .. and you can type the single names of folders to move into them. How can anyone use a computer for long and not know that you can do this?

    In regards to anyone who "isn't able to duplicate this", there are SOME styles or modes of file open/save dialogs that do not allow typing.

    Programmers: These file dialogs suck. Do not use them in your programs. They tick me off. Learn how to pass in the correct parameters to the Windows API to give the new extended functionality so that people can type rather than being forced to use the mouse. Seriously. Don't be stupid with your software. Some of your potential customers can type and do so because it's faster than using the mouse.

  16. Troll says:

    Thankfully with Vista, Explorer got it as well thru Windows Search. XP users can also get it by installing StExBar. The latest version behaves like Windows Search, version 1.5.1 and earlier had true wildcard selection.

  17. David Heffernan says:

    I can barely believe that common file dialogs started at Win 3.1.  As my first Windows was 3.11 for Workgroups I guess I don't recall what it was like before they existed.  Can anyone remember what the prevailing apps of the day did before the common dialogs?  Did every app really write their own file dialog?

    [Yes, every app wrote their own custom file dialog. That's why we have the DlgDirList function. -Raymond]
  18. Hans says:

    Sure windows 3.1. had common file dialog, see

    insanecoding.blogspot.com/…/file-dialogs.html

  19. David Heffernan says:

    DlgDirList: wow, what an awesome function!  I love the Windows file dialogs, especially the awesome Vista one which allows you to search.

  20. David Heffernan says:

    @Hans thanks for repeating what Raymond stated and letting us know that Win 3.1 had common file dialogs.  That article you linked to made me laugh.  Who knew about Windows 4 and Windows 5?  I'm dying to learn more about them!!

  21. Dan Bugglin says:

    I regularly type the filter * into dialog boxes that do not have an "All Files" drop down option to filter by * that way.

    @Sam sounds more like whoever coded the dialogs (or extended the normal dialogs, which is what I thought Office did, not sure) didn't know about this feature either!

  22. Henke37 says:

    About not knowing about things despite using computers for a long time, try this: shift+insert. You'd be lucky to know someone who can recall what that does without either trying it or looking it up.

  23. djhayman says:

    Shift+Delete = Cut

    Shift+Insert = Paste

    Sometimes, I accidentally hit Shift+Delete while moving the text selection around with the keyboard (Ctrl+Shift+Home or Ctrl+Shift+End), and it still stops me dead in my tracks wondering what I just did  ;-)

  24. Adam Rosenfield says:

    @Random832: Oh shoot, you're right, almost all of what I've said here is wrong.  I started with Cygwin to create the file with a question mark in its name and I didn't realize that it was *Cygwin* that was translating U+003F to U+F03F.  U+003F _is_ a legal character in NTFS, but it's not supported by Windows even at the CreateFileW level.  At that point, everything was looking at U+F03F and treating it normally.  I wonder how Windows would react, though, if some other OS put a file on the file system that did have U+003F in the filename.

    Sorry for the incorrect information.

  25. Brian (different Brian) says:

    It's funny the things we know and the things we don't.  I use <shift>+insert all the time (it's paste, and it works in some places that <ctrl>-v doesn't), but I'd never thought of using wildcards (globbing) in dialogs.  Note that I come from DOS 3.3, have used Linux for a decade, and have hotkeys to launch cygwin in a putty terminal on my Windows 7 box at home.  I write simple little inline loops to do things while I'm navigating around on a command line, but I would never expect them to work in a file dialog.

    One other little UI thing;  going from Windows XP to Windows 7 broke my flow for quite a while because I had originally stumbled on different ways of using the Explorer shell back in Windows 95.  To get to the address bar and type a directory path I'd <win>-E then F4 F4, which would highlight the address bar and I'd start typing.  Then it was "broken" in Win7.  A coworker said "just use <alt>-D".  Ditto for backspace vs <alt>-up.

  26. Alex says:

    Really funny people don't know it, yep. I have never (well rarely) used the drop down for file types. You can't navigate it quickly AND precisely enough for filtering in a program that has a lot of filters. So I basically always type *.XXX or simply *<enter>, when the default is say, some obscure MS format but I really want to import a CSV file and there are only CSV files in the directory anyway.

    Also great: You already are at the folder your files are located at in explorer and now you want to open a bunch of files. Copy the URL from the location bar (you all have it enabled, right?) and paste the URL into the open dialog. Now hit enter and you are there. I can't believe that there are still programs out there though, where this is greeted with an error message that the program can't open "folder xyz". Unbelievably stupid!

  27. Thank You different Brian says:

    "Ditto for backspace vs <alt>-up"

    THANK YOU VERY MUCH!!!  That has made me so angry the occasional times I have had to use Vista / Win7.  

  28. Joshua says:

    Just to clarify, it is *not* Windows that is storing question marks as U+F03F but Cygwin. Windows is displaying the middle dot because it doesn't know what glyph to use. If you type U+F03F character into the filename it shows up as question mark in Cygwin because that's what Cygwin does.

  29. Jon says:

    Ah, discoverability. Hint to Microsoft UI developers: Tooltips.

  30. Maurits says:

    > navigating to a new folder (like or *)

    , I believe. But *?

  31. Joe says:

    One sign that someone has been around since the old days is that thay use "*.*" instead of "*" when doing a FindFirst/FindNext.

  32. Kyle says:

    "One sign that someone has been around since the old days is that thay use "*.*" instead of "*" when doing a FindFirst/FindNext."

    I *still* find myself using "*.*".

  33. Gabe says:

    Joe: I have a coworker who never used Windows before Win95, yet he always uses *.* when he wants all files. He also calls console windows "DOS windows" even though he never used DOS.

  34. Neil says:

    I just realised that I implemented my own file open dialog in a app that I wrote 17 years ago. And yes, it seems I faithfully copied the Windows 3.1/NT3.51 bug ;-)

  35. Cheong says:

    I *still* find myself using "*.*". +1

    Actually if you pay attention to those applications offering "All files" in file filter, most of them still using "*.*".

    For a related trick, I remember that in the win98 days, I used to type "\localhost" and then ".." to view all computers in the file dialog ("\localhost.." won't work). I checked this trick and confirmed it still works in Win7.

  36. Engywuck says:

    It's perfectly possible to create Files on a FAT or NTFS partition which are undeletable by Winows. Just mount the partition in the Linux distribution of your choice and generate them…

    Mind you, it's even possible to create files in Linux which are non (easily) removable again in the same OS. just try to rm a file called "*" (without the quotes) ;-) Yes, you can do so by escaping the *, but you have to do so (and know about). Some years ago I knew some GUI programs which didn't…. Other nice candidates are ".txt, ?.[ etc :D Essentially Bobby Tables for file names.

  37. AsmGuru62 says:

    "17 years"?!.. nice.

    I just did my custom File Dialog last year – it loads about 40 times faster than the common one provided by Windows. Obviously, CoInitialize, etc. takes a long time.

  38. Neil says:

    NT3.51 has a bug in its common file dialog in that it doesn't filter for duplicates, so something like *t*;*x* will show you files containing both t and x twice.

  39. Karellen says:

    @Engywuck: Well, yes, if you don't escape or quote shell special characters when you're working from a shell, then the shell will interpret them as special characters. The solution is obviously to escape or quote them. Why is that surprising? Or use a different shell which uses different special characters.

    I am somewhat suspicious about your claim that there were GUI programs which didn't escape "*" – that implies that the GUI was not just spawning an external program (e.g. "rm") to delete a selected file, but spawning a shell (which is what does the "*" expansion) to run the program, which seems an incredibly round-about way of doing things. Why would the GUI app not just call unlink(2) directly? Can you remember the name of this app?

    Going even more off-topic (sorry) – one other useful hint for working with oddly-named files from a shell is prefixing individual filenames with "./", or prefixing a list of filenames with the option "–", to prevent programs treating a filename beginning with a hyphen as an option rather than a filename; e.g. "rm ./-f" or "rm — -f"

  40. Dean Harding says:

    @AsmGuru62: How slowly is the built-in file dialog loading for you anyway? Only takes a fraction of a second for me…

  41. Cherry says:

    @Adam Rosenfield: You can actually create files and folders with illegal characters in it in Windows. This works on the command line, when you escape the name with the prefix "\?" which disables name parsing (as far as I know) and put it between double quotes.

    Examples (just folders here):

    md "\?c: "

    …creates a folder with a space as name.

    md "\?c:nul"

    …creates a folder with the name "nul". If you try to rename that folder in Windows Vista or 7, you get an infinite error loop.

    md "\?c:…"

    …creates a folder with three dots as name.

    • etc.

    Best regards,

    Cherry

  42. Engywuck says:

    @Karellen: sorry, this was in KDE 2 times, so I don't remember the name. But yes, as far as I recall they essentially were a nice GUI on a sort-of-shellscript that didn't excape properly.

    And sure, we know how to delete those files (or even the trick of adding a "-f" file so "xyz *" gets this flag, but I've seen too many people struggle

    @Cherry: thanks for the hints. Just tested them :) One difference for me: the "nul" folder only gave one error message when trying to rename via Explorer. Something about "too big for the file system". Oh, and it wants admin privileges for renaming…. Tested on an USB stick and Win7 Pro, in case this matters

  43. Cherry says:

    @Engywuck: Oh, I just tested it and found out the infinite error loop only happens when the folder is on the desktop.

    @Adam Rosenfield: Yes, you are right, but that still let's you experience some basic weirdness of several applications or Windows itself when an invalid filename is encountered.

  44. Cesar says:

    Since everyone seems to be talking about illegal characters and escapes, let me leave a somewhat related link here: "Fixing Unix/Linux/POSIX Filenames:

    Control Characters (such as Newline), Leading Dashes, and Other Problems" by David A. Wheeler, at http://www.dwheeler.com/…/fixing-unix-linux-filenames.html

  45. yuhong2 says:

    "He also calls console windows "DOS windows" even though he never used DOS."

    Technically, in Win9x console windows really were DOS windows. It was NT where console windows were not DOS windows, even though NT prior to Windows 2000 misleadingly called the shortcut the "MS-DOS Prompt".

  46. Adam Rosenfield says:

    @Cherry: That allows you to create filenames with illegal *whole names*, but it still does not let you create filenames with illegal *characters* such as ? or *.  When you use the \? syntax, yes, it disables filename parsing, which allows you to control the exact path that gets passed to CreateFileW, but it doesn't change whether or not CreateFileW accepts your filename or not.

    CreateFileW fails with ERROR_INVALID_NAME ("The filename, directory name, or volume label syntax is incorrect.") if you pass in a filename containing an illegal character, whether or not you use the \? prefix.

Comments are closed.