Inconsistent behavior in Directory.GetDirectories when using long path prefix (\\?\)

[nick-beer]

While porting to .NET Core, our test suite uncovered a difference in behavior in the Directory.GetDirectories API depending upon whether the long path prefix "\\?\" is used or not. Consider the following code:

using System;
using System.Diagnostics;
using System.IO;

namespace GetDirectories
{
    class Program
    {
        static void Main(string[] args)
        {
            Exception e1 = null, e2 = null;
            string[] results1, results2;
            try
            {
                results1 = Directory.GetDirectories(@"\\?\C:\Program Files", @"..\*");
            }
            catch (Exception e)
            {
                e1 = e;
            }

            try
            {
                results2 = Directory.GetDirectories(@"C:\Program Files", @"..\*");
            }
            catch (Exception e)
            {
                e2 = e;
            }
        }
    }
}

The first call to GetDirectories throws an IOException stating

The filename, directory name, or volume label syntax is incorrect. : '\?\C:\Program Files..'

The second call to GetDirectories returns the expected (admittedly questionably so) directories and does not throw an exception.

In .NET Framework, both calls consistently throw an ArgumentException indicating the search pattern cannot contain ..\ in order to move up directories.

[JeremyKuhne]

This is expected behavior on Core as we no longer block looking out of directories (i.e. ..). The reason the first one fails is that \\?\ is considered normalized by Windows and .. is not legitimate in a normalized path.

I'm not terribly fond of the arbitrary separation of the path/filter inputs. There is no reason outside of backward compatibility to have anything but a file filter in the searchPattern. The code that handles this is here.

I'm inclined to make a breaking change in 5.0 to no longer support passing path segments in addition to a filter in searchPattern.