Question

Is the pattern matching logic used by this API exposed for reuse somewhere in the .Net Framework?

Something of the form FilePatternMatch( string searchPattern, stringfileNameToTest ) is what I’m looking for.

I’m implementing a temporary workaround for WP7 not filtering the results for this overload and I’d like the solution to both provide a consistent experience and avoid reinventing this functionality if it is exposed.

If the behaviour is not exposed for reuse, a regular expression solution (like glob pattern matching in .NET) will suffice and would save me spending the time to test the fine details of what the behaviour should be.

Perhaps one of the answers posted in the thread linked above is correct. Since I haven’t confirmed the exact behaviour as yet, I wasn’t able to determine this at a glance. Feel free to point me to one of those answers if you know it is behaviouraly an exact match to the API referenced in the question title.

I could assume the pattern matching is consistent with how DOS handled * and ? in 8.3 file names (I’m familiar with behavioural nuances of that implementation), but it’s reasonable to assume Microsoft has evolved pattern matching behaviour for file names in the decade+ since so I thought I would check before proceeding on that assumption.

Answer 1

The pattern matching rules used by IsolatedStorageFile.GetFileNames() is the same as that used in System.IO.Path. They both use the Win32 API FindFirstFile/FindNextFile Functions, namely:

The directory or path, and the file
name, which can include wildcard
characters, for example, an asterisk
(*) or a question mark (?).

This parameter should not be NULL, an
invalid string (for example, an empty
string or a string that is missing the
terminating null character), or end in
a trailing backslash ().

If the string ends with a wildcard,
period (.), or directory name, the
user must have access permissions to
the root and all subdirectories on the
path.

In the ANSI version of this function,
the name is limited to MAX_PATH
characters. To extend this limit to
32,767 widecharacters, call the
Unicode version of the function and
prepend “\?\” to the path. For more
information, see Naming a File

.