【问题标题】:DirectoryInfo.GetFiles method not returning any filesDirectoryInfo.GetFiles 方法不返回任何文件
【发布时间】:2012-02-28 16:08:19
【问题描述】:

我正在尝试返回存在于%WINDIR%\System32\inetsrv\config 中的.config 文件。

为此,我使用以下代码:

DirectoryInfo configFolder = new DirectoryInfo(Environment.ExpandEnvironmentVariables("%WINDIR%") + @"\System32\inetsrv\");
FileInfo[] configFiles = configFolder.GetFiles("*.config");

这会将零个对象返回到configFiles。如果我使用另一个文件夹(比如 D:\DropBox)就可以了!

这段代码以前可以工作,有什么变化吗??

另外,FileInfo fi = new FileInfo(Path.Combine(configPath, "applicationHost.config")); 返回正常,但 fi.Length 抛出 FileNotFoundException

好像一定是权限,但是代码运行的时候看不到怎么检查自己是否有权限!

【问题讨论】:

  • 权限?正在使用的安全上下文可能没有对该位置的读取访问权限并且看到 0 个文件。
  • 您是在 64 位环境中运行它吗?如果是这样,如果将 System32 更改为 SysWOW64 会发生什么?
  • @AndreLoker 没什么区别...不过我在 x64 上
  • 也许您错过了路径中的配置文件夹? Environment.ExpandEnvironmentVariables("%WINDIR%") + @"\System32\inetsrv\config"
  • @roymustang86 虽然这是一个错字,但我错过了我的测试代码中的配置(字面意思是上面的行),但遗憾的是它仍然不起作用。

标签: c# fileinfo directoryinfo system.io.fileinfo


【解决方案1】:

您需要以提升的权限运行代码,因为您正在尝试访问系统文件夹。

如果您使用 Windows 资源管理器 -> 属性 -> 安全性检查它,您会发现该文件夹限制了对 SYSTEM、Administrators 和 TrustedInstaller 的访问(不知道最后一个来自哪里,还不如只在我的机器...)。

您可以像这样在 App.config 文件中配置执行级别:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
</assembly>

你可以在这里找到一篇文章:How To Force C# Application To Only Run As Administrator In Windows

【讨论】:

  • 我将以上内容添加到我的 app.config 中,正如您链接到的文章中所说的那样,带有清单文件。都没有奏效。我将文件夹更改为 `C:\Windows\System32` 并且它可以工作...:S
【解决方案2】:

由于我不是开发人员,而且我只涉足代码(主要是为自己编写管理工具),我想知道是否有人可以解释或指出正确的答案位置?

基本上,我从其他人的项目中获得了一些有效的代码,并将其复制到我自己的项目中。我很确定它以前有效,但不能 100% 确定。那时我在运行 x86 Windows,但我现在在 x64 上。

旧代码仍然有效,所以我复制了设置并最终找到了解决方案。

ProjectBuild properties 中的“平台目标”设置为Any CPU(来自x86)使其工作。将其设置为 x64 也可以,但我认为这是一些安全问题。

不管怎样,问题解决了!感谢您的所有建议!

【讨论】:

    【解决方案3】:

    这不是权限问题,但实际上与幕后发生的 SysWow64 方向有关。 C:\windows\system32 被隐式重定向到 C:\windows\syswow64。这就是为什么更改构建架构可以解决问题的原因。一种适用于任何构建架构的替代方法是禁用重定向:

    [DllImport("kernel32.dll", SetLastError = true)]
    public static extern bool Wow64DisableWow64FsRedirection(ref IntPtr ptr);
    
    IntPtr ptr = new IntPtr();
    Wow64DisableWow64FsRedirection(ref ptr);
    

    请注意,这是每个线程的设置,因此在使用 GetFiles() 之前,它必须在正确的线程中运行。

    【讨论】:

    • 这听起来很有趣......我问这个问题已经有一段时间了,但我会尝试挖掘我的旧代码,看看这是否确实解决了问题,无论架构如何......谢谢!
    猜你喜欢
    • 1970-01-01
    • 2018-02-07
    • 1970-01-01
    • 2015-11-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-10-23
    相关资源
    最近更新 更多