2010-02-08 19 views
8

Estoy tratando de crear un directorio remoto y luego escribir un archivo en él. De vez en cuando, la aplicación falla con System.IO.DirectoryNotFoundException cuando intenta escribir el archivo.Directory.CreateDirectory Latency Issue?

Cuando escribo el archivo, uso el objeto devuelto DirectoryInfo para ayudar a crear la ruta del archivo, por lo que la aplicación parece pensar que el directorio se ha creado. Sin embargo, el directorio no existe.

¿Hay alguna posibilidad de que intente escribir en el directorio antes de que Windows haya terminado de crearlo? Creo que Directory.CreateDirectory no volvería hasta que esta tarea haya terminado.

+0

No tengo una buena respuesta pero no dice qué "remoto" es necesariamente. Así que tal vez se trate de un caso en el que el servidor remoto haya creado la carpeta en el sistema de archivos local pero no la haya devuelto al navegar. Tal vez un problema de almacenamiento en caché (¿algo realmente almacena en caché la estructura del sistema de archivos?). –

+0

¿El servidor remoto es un servidor de Windows o un tipo diferente de servidor que ejecuta Samba o similar? – Jacob

+0

Es un recurso compartido de IFS en un AS400. La aplicación se ejecuta en un cuadro de Windows, accediendo al recurso compartido IFS con una ruta UNC. – majorpayne27

Respuesta

7

Respuesta - Sí. El comportamiento, cuando se espera la creación de archivos/directorios, es esperado. La solución ordinaria propuesta por el otro comentarista es usar reintentos con algún tiempo de espera. El comportamiento es el mismo independientemente de las funciones de archivo utilizadas: Findfirst, CreateFile, WaitForSingleObject, etc.

Otra solución será utilizar las nuevas funciones transaccionales de API que se encuentran en Windows Vista y posterior.

El problema es desagradable y nunca fue entendido por los desarrolladores de proyectos intensivos en archivos hechos en otras plataformas y movidos a Windows: como scripts DOS/CMD, clientes SVN, Cygwin, perl, varias aplicaciones Java, varios instaladores, etc.

+1

+1 Vemos esto todo el tiempo, hasta el punto de que tenemos una biblioteca completa de llamadas IO que se han ajustado a nuestra configuración de NAS. –

+0

¿Alguien sabe cuáles son esos otros métodos mágicos? – Mrchief

4

Aunque nunca he experimentado este comportamiento y no puedo explicarlo, una solución pragmática es configurar un bucle alrededor de su llamada accediendo al directorio. Capture DirectoryNotFoundException dentro de ese bucle y vuelva a intentar el acceso algunas veces después de una breve pausa cada vez. Retome la excepción si se excede el recuento de reintentos.

Agregar un registro detallado en este momento puede ayudarlo a determinar la causa real del problema.

+0

Puede ser más eficiente comprobar 'Directory.Exists()' en lugar de capturar la excepción a menos que sea falsamente verdadera y, sin embargo, acceda a ella. –

+0

@CoryCharlton: ¿Cómo es esto más eficiente? Verificar el sistema de archivos es un orden de magnitud peor que lanzar y verificar una excepción, y presumiblemente, el sistema de archivos también haría Directory.Exists() en ese caso de todos modos. – Arafangion

6

acabo de tener este problema y para mí la situación era la siguiente:

if(!exportDirectory.Exists) 
    exportDirectory.Create(); 

Luego, más tarde, cuando en otra clase que tiene esta misma DirectoryInfo objeto pasado a él hago un:

if (!exportDirectory.Exists) 
    throw new DirectoryNotFoundException(exportDirectory.FullName); 

Y el directorio aparentemente todavía no existe (aunque tengo el directorio padre abierto en Windows y por supuesto puedo verlo justo en frente de mí).

La solución que encontré es después de la creación inicial del directorio debería estar llamando a:

exportDirectory.Refresh(); 

De Microsoft:

refresca el estado del objeto. (Se hereda de FileSystemInfo).