El comportamiento de bloqueo es diferente a través de los recursos compartidos de red

Question

He intentado bloquear un archivo para que otros servicios clonados no puedan acceder al archivo. Luego leo el archivo y luego muevo el archivo cuando termina. El movimiento está permitido usando FileShare.Delete.

Sin embargo, en las pruebas posteriores, encontramos que este enfoque no funciona si estamos buscando un recurso compartido de red. Aprecio que mi enfoque no haya sido el mejor, pero mi pregunta específica es:

¿Por qué la demostración siguiente funciona contra el archivo local, pero no contra el archivo de red?

Cuanto más específico puede ser mejor, ya que he encontrado muy poca información en mis búsquedas que indique que los recursos compartidos de red se comportan de manera diferente a los discos locales.

string sourceFile = @"C:\TestFile.txt"; 
string localPath = @"C:\MyLocalFolder\TestFile.txt"; 
string networkPath = @"\\MyMachine\MyNetworkFolder\TestFile.txt"; 

File.WriteAllText(sourceFile, "Test data"); 

if (!File.Exists(localPath)) 
    File.Copy(sourceFile, localPath); 

foreach (string path in new string[] { localPath, networkPath }) 
{ 
    using (FileStream fsLock = File.Open(path, FileMode.Open, FileAccess.ReadWrite, (FileShare.Read | FileShare.Delete))) 
    { 
     string target = path + ".out"; 
     File.Move(path, target); //This is the point of failure, when working with networkPath 

     if (File.Exists(target)) 
      File.Delete(target); 
    } 

    if (!File.Exists(path)) 
     File.Copy(sourceFile, path); 
} 

EDIT: Vale la pena mencionar que si se desea mover el archivo de un recurso compartido de red, a otro recurso compartido de red, mientras que el bloqueo está en su lugar, esto funciona. El problema solo parece ocurrir al mover un archivo dentro de el mismo archivo compartido mientras está bloqueado.

Answer 1

Creo que System.IO.File.Open() se asigna a la función Win32 API CreateFile(). En la documentación de Microsoft para esta función [http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx], menciona lo siguiente:

Windows Server 2003 y Windows XP/2000: Un intercambio de violación se produce cuando se intenta abrir un archivo o directorio para su eliminación en un equipo remoto computadora cuando el valor del parámetro dwDesiredAccess es el indicador de acceso DELETE (0x00010000) OR'ed con cualquier otro indicador de acceso, y el archivo o directorio remoto no se ha abierto con FILE_SHARE_DELETE. Para evitar la infracción de uso compartido en este escenario, abra el archivo o directorio remoto con el acceso DELETE solo a la derecha, o llame a DeleteFile sin abrir primero el archivo o directorio para su eliminación.

De acuerdo con esto, tendrías que pasar DELETE como el parámetro FileAccess a IO.File.Open(). Desafortunadamente, la enumeración DELETE no se incluyó como una opción.

Este problema solo se aplica a Windows 2003 y anteriores. He probado su código en Windows 2008 R2 SP1, y funciona bien. Por lo tanto, es posible que también funcione en Windows 2008 también.