.NET 8 DirectoryInfo.EnumerateFiles with MatchCasing.CaseInsensitive fails on Linux

[Viech3]

Description

.NET 8.0.302
Ubuntu 22.04.3 LTS

Hi,

I have an Issue with DirectoryInfo.EnumerateFiles. It works fine on windows, but on Linux I have trouble with case insensitive searches.

When I search for "LOG/*.txt" I expect it to find "log/test.txt", but on Linux I get an "DirectoryNotFoundException": Could not find a part of the path '/home/user/publish/LOG'.

Reproduction Steps

Build and Execute following code on Linux:

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            if(!Directory.Exists("log"))
                Directory.CreateDirectory("log");

            if (!File.Exists("log/test.txt"))
                File.Create("log/test.txt").Dispose();

            var files = new DirectoryInfo(Environment.CurrentDirectory).EnumerateFiles("LOG/*.txt", new EnumerationOptions { MatchCasing = MatchCasing.CaseInsensitive });

            foreach (var file in files)
            {
                Console.WriteLine(file.FullName);
            }

            Console.WriteLine("Finished");
        }
    }
}

Expected behavior

Console displays "..../log/test.txt"

Actual behavior

Error is thrown:

Unhandled exception. System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/user/publish/LOG'.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

[jozkee]

Linux filesystems are usually case-sensitive, you are probably using ext4 since that's Ubuntu's default. You can try mounting a FAT filesystem and that I think should give you case insensitive results.

[jozkee]

I don't notice you were using MatchCasing.CaseInsensitive. This is a bug.

We have logic that modifies the path and the searchPattern (expression).

runtime/src/libraries/System.Private.CoreLib/src/System/IO/Enumeration/FileSystemEnumerableFactory.cs

Lines 38 to 43 in 2f09bfa

	// We always allowed breaking the passed ref directory and filter to be separated
	// any way the user wanted. Looking for "C:\foo\*.cs" could be passed as "C:\" and
	// "foo\*.cs" or "C:\foo" and "*.cs", for example. As such we need to combine and
	// split the inputs if the expression contains a directory separator.
	//
	// We also allowed for expression to be "foo\" which would translate to "foo\*".

Basically, your path /home/user/publish and your pattern LOG/*.txt are turned into /home/user/publish/LOG and *.txt.
Because of that, opendir fails with the exception you are seeing.

I'm not sure what would happen if we stopped doing that. this requires experimentation.

[jozkee]

cc @JeremyKuhne

[JeremyKuhne]

@jozkee Just a weird corner case due to existing behavior. Changing this would be pretty breaking. We should make sure the docs are clear on this behavior. The answer here is don't put subdirectories in the second argument I believe.