2009-05-26 14 views
7

El proceso es elevado y me aseguré de que la ruta era correcta en el depurador VS (estoy usando Environment.GetFolderPath (Environment.SpecialFolder.System) no codificándolo con dificultad) pero File.Exists aún devuelve false..NET File.Exists no funciona en la carpeta Windows System32 Drivers?

La razón por la que lo necesito es una solución para garantizar que algunos controladores de terceros estén instalados porque sus configuraciones de registro no se eliminan en la desinstalación.

Sé que las escrituras se redirigen a través de la virtualización, pero ¿esto también es cierto para verificar la existencia de un archivo?

+0

Funciona bien para mí. ¿Cuál es tu entorno? – Noldorin

Respuesta

10

Sí, la virtualización ocurre en un nivel muy bajo. El método File.Exists básicamente llama al método Win32 CreateFile y comprueba si hay errores. CreateFile es redirigido por el subsistema WOW.

Puede desactivar la virtualización temporalmente antes de llamar.

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

[DllImport("kernel32", CharSet=CharSet.Unicode, SetLastError=true)] 
public static extern bool Wow64RevertWow64FsRedirection(IntPtr oldValue); 

Por supuesto, para estar completo, deberá verificar la existencia del archivo con la virtualización activada y desactivada. Lo mismo se aplica para verificar entradas de registro también.

public static bool FileExists(string path) 
{ 
    if(File.Exists(path)) return true; 
    IntPtr oldValue = IntPtr.Zero; 
    try 
    { 
     if(Environment.GetEnvironmentVariable("PROCESSOR_ARCHITEW6432") == null) 
      return false; 

     Wow64DisableWow64FsRedirection(ref oldValue); 
     if(File.Exists(path)) return true; 

     return false; 
    } 
    finally 
    { 
     if(oldValue != IntPtr.Zero) 
      Wow64RevertWow64FsRedirection(ref oldValue);    
    } 
} 

Actualización: También puede ser necesario para comprobar la versión del sistema operativo antes de deshabilitar la redirección WOW porque las versiones anteriores de XP (SP2 Pre creo) no exponen esos métodos.

Actualización 2: Comprobación de sistema operativo añadida para 64 bits. Todas las versiones de 64 bits del sistema operativo implementan estos métodos y solo necesita desactivar el estado si se ejecuta en un sistema operativo de 64 bits.

+0

¿Entonces con el intento/finalmente todavía necesito verificar la versión del sistema operativo? Supongo que el bloque finally también lanzaría si no es compatible. – Davy8

+0

Sí, el bloque finally aún llama al método Wow64XXX. –

2

¿Su proceso es de 32 bits o de 64 bits? y son los conductores 64 o 32? A lo que me refiero es que tal vez su OS host lo redirija a la carpeta Wow64.

0

Este es un problema de virtualización, el archivo simplemente no está allí. Tendrá que buscarlo en la carpeta que contiene los archivos virtualizados.

0

Si tiene los derechos, ¿por qué no intenta crear un archivo en la misma ubicación en su código y ver dónde termina? Según lo sugerido por otro, Windows podría estar redireccionando su llamada en función de algunas configuraciones.

Además, podría intentar hacer un DirectoryInfo y enumerar los archivos que contiene para ver si algo le parece familiar.

2

¿Has probado disabling folder virtualization para tu aplicación? Tendrá que añadir un archivo de manifiesto que contiene:

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

Sin embargo, si necesita escribir en esas carpetas que tendrá que request admin ability. Para hacer eso, cambie level="asInvoker" a level="requireAdministrator" en el xml.

Cuestiones relacionadas