.net Directory.GetParent中的Bug？

System.IO.Directory.GetParent方法的一个非常奇怪的行为击中了我的脸：

string path1 = @"C:\foo\bar";
DirectoryInfo parent1 = Directory.GetParent(path1);
Console.WriteLine (parent1.FullName); // Prints C:\foo, as expected

// Notice the extra backslash. It should still refer to the same location, right ?
string path2 = @"C:\foo\bar\";
DirectoryInfo parent2 = Directory.GetParent(path2);
Console.WriteLine (parent2.FullName); // Prints C:\foo\bar !!!

我认为这是一个错误，但是这种方法自1以来就一直存在，所以我想它现在已经被检测出来了。另一方面，如果它的设计，我想不出一个合理的解释，这样的设计

你觉得怎么样？是虫子吗？如果不是，你如何解释这种行为？
一些谷歌搜索显示：

及

DirectoryInfo di = new DirectoryInfo(@"C:\parent\child\");
Console.WriteLine(di.Parent.FullName);

两者都返回“C:\parent”

我只能假设
目录。GetParent（…）
不能假设
C:\parent\child
是一个目录，而不是没有文件扩展名的文件
DirectoryInfo
可以，因为您是这样构造对象的


我个人认为，当有反斜杠时，字符串被视为目录中“null文件”（即没有名称和扩展名的文件）的路径。显然，这些可能存在（应该有一个链接，但出于某种原因，我找不到任何东西）

尝试从
path2
构建
FileInfo
对象。您将看到它构造正确，名称和扩展名为
String.Empty
，不存在，并且
C:\foo\bar
作为其
DirectoryName
。考虑到这一点，这种情况是有意义的：这个“空文件”的父对象确实是
C:\foo\bar
，这非常有趣。首先，当我读到这篇文章时，我非常确定这是一个bug，但当我再仔细考虑它时，我得出结论，其目的可能是路径不应该是目录，而应该是文件的完整或相对路径。所以

c:\somenonexistingpath\指向\a\目录\

被解释为指向…\directory中没有名称的文件的路径。这有点傻，但是如果我们假设微软的程序员期望一个文件的完整路径，那么不讨论这个问题是有道理的

编辑：

注意

c:\dir\makefile->c:\dir

c:\dir\build.msbuild->c:\dir

如预期的那样给予父母。
我同意格斯伯格的观点。为了增加一些额外的火力，我将添加以下使用Reflector获得的代码片段

Directory.GetParent函数基本上只调用Path.GetDirectoryName函数：

[SecuritySafeCritical]
public static DirectoryInfo GetParent(string path)
{
    if (path == null)
    {
        throw new ArgumentNullException("path");
    }
    if (path.Length == 0)
    {
        throw new ArgumentException(Environment.GetResourceString("Argument_PathEmpty"), "path");
    }
    string directoryName = Path.GetDirectoryName(Path.GetFullPathInternal(path));
    if (directoryName == null)
    {
        return null;
    }
    return new DirectoryInfo(directoryName);
}

DirectoryInfo的父属性基本上去掉了尾随斜杠，然后调用Path.GetDirectoryName:

public DirectoryInfo Parent
{
    [SecuritySafeCritical]
    get
    {
        string fullPath = base.FullPath;
        if ((fullPath.Length > 3) && fullPath.EndsWith(Path.DirectorySeparatorChar))
        {
            fullPath = base.FullPath.Substring(0, base.FullPath.Length - 1);
        }
        string directoryName = Path.GetDirectoryName(fullPath);
        if (directoryName == null)
        {
            return null;
        }
        DirectoryInfo info = new DirectoryInfo(directoryName, false);
        new FileIOPermission(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, info.demandDir, false, false).Demand();
        return info;
    }
}

是的，我想到过这样的事情，但它没有真正意义：没有最后一个反斜杠的情况很好（父项是
C:\parent
无论
child
是文件还是目录），最后一个反斜杠失败的情况是：
C:\parent\child`显然是一个目录，而不是文件（没有文件路径以反斜杠结尾）。即使它*可能*是一个文件，它的父级仍然应该是
c:\parent`……关于
new DirectoryInfo的解决方法
：这就是我最终做的。实际上，我的问题不是关于“如何解决该问题”，而是关于“它为什么会这样做”+1作为您的最后一次编辑。现在，我想这是有意义的…尽管我不会以有意义的方式设计它，但文档没有说明路径是文件或目录路径…我假设如果方法需要文件路径，他们会提到它。而没有名称的文件则没有太多意义；）。不管怎么说，我想我要在Connect上提交一份bug报告，看看微软对此有何评论。一个没有名字的文件没有意义，但我的论点是，他们没有期望人们会假设一个目录路径。我同意文档应该更清晰。认识到为什么.NET framework有两个处理目录的类是很重要的。其中一个猜测，另一个验证。你知道区别。@Hans:实际上，目录和目录信息都不能验证任何东西。。。我用于测试的路径实际上并不存在于我的文件系统中，两个类都非常乐意处理它（当然，只要我不做真正需要该路径存在的事情）。无论如何，显然目录猜错了。。。在我看来，它应该像sameI应该验证的那样准确地处理这两条路径，但是，唉，它是可修复的可能性非常小。没什么意义。将此发布到connect.microsoft。com@Hans，我同意：即使是一个bug，修复它也是一个突破性的改变，所以他们可能不会这么做。我不管怎样…这种行为现在被记录下来了。很有趣。。。我甚至没有想过用反射器检查（和我很不一样…）。所以问题实际上是Path.GetDirectoryName，而不是Directory.GetParent
public DirectoryInfo Parent
{
    [SecuritySafeCritical]
    get
    {
        string fullPath = base.FullPath;
        if ((fullPath.Length > 3) && fullPath.EndsWith(Path.DirectorySeparatorChar))
        {
            fullPath = base.FullPath.Substring(0, base.FullPath.Length - 1);
        }
        string directoryName = Path.GetDirectoryName(fullPath);
        if (directoryName == null)
        {
            return null;
        }
        DirectoryInfo info = new DirectoryInfo(directoryName, false);
        new FileIOPermission(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, info.demandDir, false, false).Demand();
        return info;
    }
}