visual net metodo filecopy ejemplo delete copiar archivos .net file-locking

.net - net - metodo copy en c#



File.Copy bloquea el archivo fuente después de completar (2)

No puedo replicar esto en nuestros servidores de archivos.

Sin embargo, sí sé que el bloqueo oportunista está deshabilitado ya que estamos usando PeerLock by PeerSoftware.

Estamos intentando copiar un archivo desde un servidor, a una máquina local en una aplicación .NET 2.0 (C #), pero mantenemos el archivo de origen innecesariamente bloqueado. Sospechamos que es algo configurado en el servidor de archivos el que está causando este comportamiento, pero no estamos seguros de qué ... ¿puede ayudarnos?

Después de la operación de copia de archivos, el servidor de archivos (Windows 2K3 R2) informa que el archivo de origen se mantiene con un bloqueo de lectura, aunque no se realiza ninguna otra operación con el archivo en el servidor. El bloqueo se libera una vez que se cierra la aplicación.

Podemos reproducir el comportamiento, incluso con el código más básico que se ve a continuación:

static void Main(string[] args) { string sourceFile = @"//win2K3server/resource/Production/IQE/sourceFolder/iqeconsole.exe"; string destinationFile = @"d:/destinationFolder/iqeconsole.exe"; System.IO.File.Copy(sourceFile,destinationFile,true); Console.ReadLine(); }

El bloqueo se produce inmediatamente durante la ejecución de la línea File.Copy() , y persiste después de que esta línea haya terminado. En una aplicación más compleja, cuando la rutina con File.Copy() sale (pero la aplicación aún se está ejecutando), el bloqueo persiste.

Solo cuando se termina la aplicación completa se libera el bloqueo.

Cambiar sourceFile para usar una unidad asignada en lugar de una ruta UNC no hace ninguna diferencia en el comportamiento.

Este comportamiento no ocurre cuando el archivo de origen se encuentra en otro servidor o se encuentra localmente.

Si agregamos la siguiente línea después de File.Copy , el bloqueo se libera inmediatamente:

new System.Security.Permissions.FileIOPermission(System.Security.Permissions.FileIOPermissionAccess.Read, new string[] { sourceFile }).Demand();

Todo esto nos suena como si hay algo en el servidor que está causando este comportamiento. Tenemos ShadowProtect instalado en el servidor junto con el antivirus McAfee. Aparte de eso, parece que no hay nada más instalado por encima de Windows Server y sus componentes.

Tampoco estamos seguros de por qué exigir un permiso de lectura en el archivo resuelve el problema.

Si pudiera responder a estas preguntas, le agradeceríamos enormemente:

  1. ¿Qué está haciendo que los bloqueos de archivos persistan?
  2. ¿Por qué Exigir un permiso de lectura resuelve el problema?

Probablemente sea el escáner de acceso de McAfee el que mantiene el bloqueo. Si solo utiliza el acceso de lectura, se omite. Creo que puede usar la herramienta Sysinternals Process Viewer (gratuita de Microsoft) para confirmarlo.

No está seguro de qué suscripción tiene para McAfee, pero puede definir reglas de excepción para que no analice este archivo.