DirectoryInfo.CreateSubdirectory fails when DirectoryInfo path is a root directory

[t4m45]

Description

The same issue as #26448

Reproduction Steps

static void Main(string[] args)
{
    var d = new DirectoryInfo(@"C:\");
    d.CreateSubdirectory("bar");
}

Expected behavior

It creates the subdirectory

Actual behavior

System.ArgumentException: The directory specified, 'bar', is not a subdirectory of 'C:\'.
Parameter name: path
   at System.IO.DirectoryInfo.CreateSubdirectory(String path)
   ...

Regression?

In .NET Framework 4.8 it works fine

Known Workarounds

No response

Configuration

<TargetFramework>net8.0-windows10.0.17763.0</TargetFramework>
<OutputType>Library</OutputType>
<Platforms>x86</Platforms>

Win 11 Pro 21H2 22631.2861 x64

Other information

This doesn't throw:

    static void Main(string[] args)
    {
        var d = new DirectoryInfo(@"C:\foo");
        d.CreateSubdirectory("bar");
    }

[dotnet-policy-service]

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

[dotnet-policy-service]

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

[elgonzo]

FYI:

The title is misleading. The trailing separator is not the reason for the issue. You can observe this by doing something like this (X:\foo being an existing directory):

        var d = new DirectoryInfo(@"X:\foo\");
        d.CreateSubdirectory("bar");

this will work as expected. Note the presence of a trailing separator.

The real trigger for the issue seems to be the DirectoryInfo representing a root directory. (Knowing this, you can trigger the issue with a DirectoryInfo path for a root directory like @"X:\foo\.." -- no separator at the end, yet the issue is triggered.)

[t4m45]

Edit: I was wrong here

I can not really understand your comment.

The trailing separator in the string parameter (supplied into the constructor of DirectoryInfo) is not relevant.
It's the trailing separator at the end of the FullName (of DirectoryInfo) which is always there for a drive, like C:\

[t4m45]

I double checked it and the FullName contains the trailing separator even for subdirectories, so I was wrong.
Cannot really think about a root cause now.

The only difference I can see for "C:" and "C:\Foo" when I create a DirectoryInfo for them is their Name properties. For the first it's "C:" and for the second it is "Foo".

[elgonzo]

Cannot really think about a root cause now.

The root cause seems to be the DirectoryInfo being a root directory.

new DirectoryInfo(@"C:\") represents a root directory -- issue triggered.

new DirectoryInfo(@"C:\foo\") does not represents a root directory -- issue not triggered.

new DirectoryInfo(@"C:\foo\..") represents a root directory -- issue triggered.

Side note:

Be extremely careful with paths consisting only of a drive letters without a [back]slash. A path consisting only of a drive letter like C: does NOT specify the root directory of drive C:. It rather specifies the working directory of drive C:.

As far as .NET is concerned, if drive X is the drive of the Directory.GetCurrentDirectory() path, then the path @"X:" refers to this Directory.GetCurrentDirectory() path. If drive X is not the drive of the Directory.GetCurrentDirectory() path, then @"X:" coincides with the root directory of drive X. (Note that other runtime environments or shells might keep track of last working directory of each drive individually, so the key thing to remember here is that a path consisting only of a drive letter without [back]slash is not referring to the root directory, but to a working directory, whatever that working directory might be...)

[elgonzo]

It seems the origin of the issue is the PathInternal.IsDirectorySeparator(newPath[trimmedCurrentPath.Length]) expression in

runtime/src/libraries/System.Private.CoreLib/src/System/IO/DirectoryInfo.cs

Lines 85 to 98 in d960be8

	ReadOnlySpan<char> trimmedNewPath = Path.TrimEndingDirectorySeparator(newPath.AsSpan());
	ReadOnlySpan<char> trimmedCurrentPath = Path.TrimEndingDirectorySeparator(FullPath.AsSpan());
	// We want to make sure the requested directory is actually under the subdirectory.
	if (trimmedNewPath.StartsWith(trimmedCurrentPath, PathInternal.StringComparison)
	// Allow the exact same path, but prevent allowing "..\FooBar" through when the directory is "Foo"
	&& ((trimmedNewPath.Length == trimmedCurrentPath.Length) || PathInternal.IsDirectorySeparator(newPath[trimmedCurrentPath.Length])))
	{
	FileSystem.CreateDirectory(newPath);
	return new DirectoryInfo(newPath);
	}
	// We weren't nested
	throw new ArgumentException(SR.Format(SR.Argument_InvalidSubPath, path, FullPath), nameof(path));

For DirectoryInfo's representing root directories like C:\, Path.TrimEndingDirectorySeparator does not remove the separator from its full path, with trimmedCurrentPath then still containing the trailing separator of the root dir path.

Hence, in this situation using trimmedCurrentPath.Length as index into newPath points not at the separator but at the character after the separator, thus the if condition incorrectly fails and the subsequent ArgumentException is being thrown.

Side note: The current CreateSubdirectory implementation has further issues. For example, it likes to throw an exception when invoked like CreateSubdirectory(@"\bar") with an entirely misleading message of "Second path fragment must not be a drive or UNC name."

[danmoseley]

This is broken back at least to .NET Core 3.1 so not a recent regression, but still a regression from .NET Framework that should be fixed.

@elgonzo any interest in making a fix? no obligation to