我有以下情况：
我发布了一个页面，其中包含多个二进制文件，然后由 HTTP 接收器接收并使用进程内部署程序进行部署，所有这些文件都托管在 IIS 中作为本地服务用户运行的专用应用程序池中。
页面存储在代理数据库中，二进制文件使用“D:\Binaries\Preview”之类的路径发布到本地文件系统。
预览文件夹作为只读共享共享给域用户，位于 \machinename\PreviewBinaries 之类的位置，以便可以使用 Web 应用程序显示二进制文件。
十有八九一切正常，但偶尔发布失败，这似乎是因为二进制文件被另一个进程锁定而无法覆盖。我已经使用 ProcessMon 和其他工具来尝试确定可能锁定这些文件的原因（无济于事）。有时我可以手动删除图像，然后再次发布作品。如果我在服务器上重新启动 IIS，我总是可以删除文件并发布。
有没有人对哪些进程可以锁定这些图像有任何建议？有没有人见过这个问题？我要发布到共享中是否有任何问题？或者 SiteEdit 2009 是否可能会锁定这些文件，因为它似乎只发生在我们的预览服务器上并且实时（没有 SiteEdit）似乎很好。
提前致谢
如果您使用的是 Windows 2008，您可以尝试从磁盘中删除该文件。然后它会告诉你哪个进程锁定了文件。但是鉴于重新启动 IIS 会解锁文件，似乎很可能是 IIS 锁定了它们。
我看不出 SiteEdit 2009 如何导致锁定这些文件。鉴于您可以将预览服务器放在另一个盒子上，SiteEdit 仅通过 HTTP 与该服务器通信。它从不直接访问预览服务器上的文件，甚至不通过 CD API。只是对您的网络服务器的常规请求，就像访问者一样。
同样，不是直接的答案，但我还是想分享这个：
我见过类似的情况，我将页面发布到代理数据库并将二进制文件发布到文件系统。当我将应用程序池的标识更改为网络服务时，这个问题就消失了，我没有进一步研究它。
好的，看起来有问题的代码在我们正在使用的 Presentation Framework 中。该框架使用Response.TransmitFile(binaryPath)将二进制文件异步传输到客户端。这似乎在二进制文件上放置了一个临时锁定句柄（即使它们位于只读共享上）。
我们删除了这行代码，并以另一种方式将应用程序修改为服务器二进制文件（我们现在重写路径，以便 IIS 可以直接传输文件）。这似乎解决了问题，并提高了网站性能。
感谢您的所有建议，它帮助我排除了所有没有导致问题的事情，因此我能够找到根本原因。
是否有任何防病毒或索引服务正在运行。这些往往会在您不希望它们使用的时候使用非常短暂的锁定。特别是对于防病毒软件，这通常只是一个进程放弃它的锁定，并且就在您的另一个进程试图获取它之前。如果这是问题所在，那么设置一些排除目录应该会有所帮助。
我看到您使用过 Process Monitor，但您是否尝试过 Sysinternals Process Explorer？“Find->Find Handle or Dll”对于这类事情非常有用。或者，如果您更喜欢命令行工具，Sysinternals 也可以制作 handle.exe，它会为您转储所有内容。