DirectoryInfo.GetFiles method not returning any files

Question

I'm trying to return the .config files that exist in %WINDIR%\System32\inetsrv\config.

For this I am using the following code:

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

This returns zero objects into configFiles. If I use another folder (say D:\DropBox) is works fine!

This code used to work, has something changed??

Also, FileInfo fi = new FileInfo(Path.Combine(configPath, "applicationHost.config")); returns ok, but fi.Length throws FileNotFoundException.

Seems it must be permissions, but I can't see how to check if I have permissions when the code runs!

Medicate

Permissions perhaps? Security context being used perhaps has no read access to that location and sees 0 files. – Afroamerican

Are you running this on a 64 bit environment? If so, what happens if you change System32 to SysWOW64? – Minestrone

@AndreLoker that made no difference... I am on x64 though – Medicate

perhaps you missed the config folder in your path? Environment.ExpandEnvironmentVariables("%WINDIR%") + @"\System32\inetsrv\config" – Votive

@Votive I though it was a typo, but I had missed the config off of my testing code (literally the lines above) but sadly it still doesn't work. – Medicate

@SpaceBison Any way I can check these permissions in code? got sample code but it says I do have access and still gives me 0! – Medicate

Answer 1

As I am not a developer, and I only dabble with code (mostly writing admin tools for myself), I wonder if someone can explain or point me to the correct location for the answer?

Basically, I had some code from someone else's project that worked, and copied it to my own project. I'm pretty sure it worked before, but can't be 100% certain. At that time I was running x86 Windows, but I'm now on x64.

The old code still worked, so I went through copying the settings and eventually found the solution.

Setting "Platform Target" in the Project's Build properties to Any CPU (from x86) made it work. Setting it to x64 also worked, but I figure it is some security thing.

Anyway, problem solved! Thanks for all your suggestions!

Medicate

Answer 2

You will need to run the code with elevated priviledges because you are trying to access asystem folder.

If you examine it with the Windows Explorer -> Properties -> Security you will find that that folder restricts access to SYSTEM, Administrators and TrustedInstaller (don't know where the last comes from, might just as well be only on my machine...).

You can configure the execution level within your App.config file like this:

<?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>

You can find an article here: How To Force C# Application To Only Run As Administrator In Windows

Arette

I added the above to my app.config and as the article you linked to says with a manifest file. Neither worked. I changed the folder to `C:\Windows\System32` and it works... :S – Medicate

Answer 3

This is not a permissions issue but is actually related to the SysWow64 direction that is happening behind the scenes. C:\windows\system32 is being implicitly redirected to C:\windows\syswow64. This is why changing the build architecture fixes the issue. An alternative that works with any build architecture is to disable the redirection:

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

IntPtr ptr = new IntPtr();
Wow64DisableWow64FsRedirection(ref ptr);

Note that this is a per-thread setting so it must be run in correct thread before you use GetFiles().

Van

That sounds interesting... It's a while since I asked the question, but I will try and dig out my old code and see if this does indeed fix the problem regardless of architecture... Thanks! – Medicate