An explanation of GetInvalidPathChars in System.IO, and a nod to GetInvalidFileNameChars [Kit George]

An explanation of GetInvalidPathChars in System.IO, and a nod to GetInvalidFileNameChars [Kit George]

  • Comments 8

Something that a lot of people note with the Path class is that it has a method called 'GetInvalidPathChars', but the list doesn't return two key values which obviously, are not allowed to be used as part of file names: '*' and '?'.

The reason is that this method is intended mostly to be used by people working with our other IO APIs, where we accept a searchstring (an example is Directory.GetFiles(string path, string pattern)). The searchstring allows you to use '*' and '?' as part of the searchpattern, supporting a rudimentary searching mechanism, much to what you might expect through the command-window. This allows you to write code like so:

// searchstring here is supposedly, from some user input box

bool searchStringIsInvalid searchString.IndexOfAny(Path.GetInvalidPathChars());

So the existing method actually has a specific intent a very good usage pattern. However, many people still want the list of invalidchars, but they also want that list to contain '*' and '?', so that they can determine if a filename or directoryname provided in an input box, is valid. The solution? Keep an eye out for the new method in Whidbey on Path called 'GetInvalidFileNameChars'.

It's often those small features that can help just polish up the solution.

  • I think you mean InvalidPathChars field. GetInvalidPathChars does not exist (well at least in 1.1).
  • Sweet. I've run across this one before, looking forward to a built-in method. Will GetInvalidFileNameChars also proscribe the use of "\" and "/", which are of course perfectly reasonable for paths?
  • 'GetInvalidFileNameChars' should include the backslash character, since it's invalid in a filename. 'GetInvalidFolderNameChars' should NOT include the backslash character - natch. Er, then you would need variants of 'GetInvalidPathChars' to cope with allowing/disallowing backslashes in a wildcard scenario. Hmm... how about just one, overloaded method that takes parameters that specify all the different variations (filename, relative filename, fully-qualified pathname, folder pathname, allow-wildcards, etc.).
  • hello.txt
    hello.*
    path\hello.txt
    path\hello.*
    \\server\path\hello.txt
    \\server\path\hello.*
    c:\path\hello.txt
    c:\path\hello.*
    file:///C:/path/hello.txt

    If you had a method that could cope with all of the above variations (and any others you can think of), that would be fine and dandy. Parameters would dicate what kind of pathname you're trying to get invalid characters for, and there would be a number of overloads to allow for sensible defaults.
  • I forgot:-

    path
    \path
    ..\path
    .\path
    c:\path

    etc.
  • Some good feedback and questions here, thanks guys. Some replies:

    - Dean, We've actually obsoleted the InvalidPathChars field in whidbey, it's not a good design pattern for us to expose a public readonly reference field. We now urge you to use the replacement, GetInvalidPathChars
    - Richard, GetInvalidFileNameChars does include forward and backslash: as you say, those aren't valid characters for a file
    - Andrew, we've had a feature request for a while, to consider how we should be expose an 'IsValidPath' concept, for all the myriad variations (is file:/// allowed? What about ..\.\\././..\ variations? We've jsut never had it become a critical issue: we'll continue to triage the feature idea in the future. Thanks for the vote Andrew
Page 1 of 1 (7 items)