有两个应用程序。 第一个应用程序远离有问题的机器（并且我没有ACESSS），并通过网络（LAN）创建一个大文件。我无法控制这一过程，也不知道何时发生。这是我必须要做的事情。我无法以任何方式添加，更改或更改此内容。通过检测文件打开（创建）进程同步
第二个应用程序由我编写，并在找到它时处理此文件。这个程序计划每5分钟运行一次。
当我的应用程序尝试处理该文件导致处理不完整和/或其他错误时，可能会出现文件处于写入过程中的情况，因此我需要检测文件是否已完全写入开始处理它。
我可以使用OpenFile（）并请求读/写锁定访问。错误将表明文件正在创建。
我可能做一些巧妙的搭配文件系统观察 http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
但我怀疑有我没有的Windows（NT和更高版本）想到了一个优雅的方式
一个完全hackish的方法是在远程计算机上安装一个API钩子来关闭文件，然后启动程序或发送完成的通知。
标准解决方案是让写入者写入临时文件，然后在完成后重命名文件。
通过这种方式，读者（您的应用程序）将只能在文件完成时看到该文件。
不幸的是，我无法访问作者（远程过程）来实现这一点。 – 2009-04-17 15:25:57
是的，我注意到你已经更新了你的文章......有点OTT我不得不说！ – 2009-04-17 17:14:48
没有违法意图，只是为了清晰起见:) – 2009-04-18 01:30:09
回到过去，我不得不编写使用网络上的文件（通过Novell文件服务器在某些* NIX应用程序和Windows应用程序之间）进行通信的软件。为了可靠地做到这一点，我们总是说服数据文件的提供者在完成数据写入时创建一个额外的握手文件（只是一个空文件）。我们的应用程序将轮询握手文件，如果握手文件存在，我们读取数据文件。当我们的应用程序读完数据后，它会删除握手文件。握手文件由供应商监控，只要握手文件存在，供应商就不会触摸数据文件。
但是，大部分时间数据的提供者愿意修改他们的应用程序。我认为唯一可行的方法是从提供商处获得信号。
我认为你的系统观察者解决方案通过FileSystemWatcher或ReadDirectoryChanges是最好的，你可以得到。您也可以在CodeProject中查看this tutorial。无论如何，它有多优雅？
另一个答案，但不同：我突然想起另一个项目做了类似的事情。我的应用程序只使用OpenFile()和OF_SHARE_EXCLUSIVE（我认为），直到它成功打开文件。在这种情况下，这可以正常工作，因为我的应用程序正在访问由远程应用程序写入与我的应用程序相同的机器上的共享文件。我从来没有用文件服务器上的文件测试它，但它可以工作。但是，与远程文件一起使用时，文件锁定并不总是可靠的。
其他许多人已经指出，唯一的理智方式是一次额外的握手。因为这似乎是不可能的，我会做以下。
不幸的是，远程进程（远程机器）不可访问。 – 2009-04-17 15:25:07