我们正试图从一个服务器下的文件复制到本地计算机在.NET 2.0的应用程序（C＃），但保​​留其不必要的锁定源文件。我们怀疑它是什么，是导致此问题的文件服务器上配置的，但不知道是什么......你能帮忙吗？

文件复制操作之后，文件服务器（视窗2K3 R2）的报告，源文件被保持与一个读锁定，即使没有进一步的动作中，服务器上的文件进行。锁被释放，一旦应用程序退出。

我们能够重现行为，即使是最基本的code以下所示：

 静态无效的主要（字串[] args）
{
    字符串的资源文件= @\\ win2K3server \资源\生产\ IQE \ sourceFolder \ iqeconsole.exe;
    字符串destinationFile = @D：\ destinationFolder \ iqeconsole.exe;
    System.IO.File.Copy（的资源文件，destinationFile，真正的）;

    到Console.ReadLine（）;
}
 

锁定了 File.Copy（）行执行时立即occurrs，并坚持后，该行已完成。在更复杂的应用中，当用 File.Copy（）出口（但应用程序仍在运行）的例行程序，锁是否仍然存在。

仅当整个应用程序完成是锁释放

修改的资源文件来使用映射驱动器，而不是UNC路径不产生任何影响的行为。

此行​​为不会发生在源文件位于另一台服务器上，或位于本地。

如果我们添加以下行后 File.Copy ，锁被立即释放：

 新System.Security.Permissions.FileIOPermission(System.Security.Permissions.FileIOPermissionAccess.Read,新的String [] {}的资源文件）需求（）。
 

这一切听起来我们好像有东西，是造成这种行为的服务器上。我们已经安装在服务器上的ShadowProtect以及McAfee防病毒。除此之外，它看起来好像没有什么别的装过及以上的Windows Server及其组件。

我们也不清楚为什么该文件要求以读取权限解决了这个问题。

如果你能回答这些问题，我们将AP preciate大大：

这可能是McAfee按访问扫描程序持有锁。如果你只用读访问，它是旁路。我相信，您可以使用Sysinternals的进程查看器工具（免费从微软）来确认。

不知道你有什么订阅迈克菲，但你可以定义例外规则，以便它不扫描该文件。

We are trying to copy a file from a server, down to a local machine in a .NET 2.0 application (C#), but keep having the source file unnecessarily locked. We suspect it is something configured on the file server that is causing this behaviour, but are not sure what ... can you help?

After the file copy operation, the file server (Windows 2K3 R2) reports that the source file is being held with a read lock, even though no further operation is done with the file on the server. The lock is released once the application quits.

We are able to reproduce the behaviour, even with the most basic code seen below :

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();
}

The lock occurrs immediately during the File.Copy() line executing, and persists after this line has finished. In a more complex application, when the routine with the File.Copy() exits(but the application is still running), the lock persists.

Only when the entire application is finished is the lock released.

Changing sourceFile to use a mapped drive instead of a UNC path makes no difference to the behaviour.

This behaviour does not happen when the source file is located on another server, or is located locally.

If we add the following line after the File.Copy, the lock is released immediately :

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

This all sounds to us as though there is something on the server that is causing this behaviour. We have ShadowProtect installed on the server along with McAfee anti-virus. Apart from that, it appears as though there is nothing else installed over-and-above Windows Server and its components.

We are also not sure why Demanding a read permission on the file solves the problem.

If you could answer these questions, we would appreciate it greatly:

It is probably the McAfee on-access scanner that holds the lock. If you only use read access, it is bypassed. I believe that you can use the Sysinternals Process Viewer tool (free from Microsoft) to confirm that.

Not sure what subscription you have for McAfee, but you can define exception rules so that it does not scan this file.