这有点令人费解，但我会尽量解释清楚。
我正在使用带有通知过滤器的 FileSystemWatcher
toFileWatcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.FileName;
我有一个 .Created 方法和一个 .Changed 方法。
当 .Created 事件触发时，它会使用观察者提供的文件名进行一些初步检查，检查文件是否已被看到，获取目标文件夹，并返回验证信息。
我遇到了一个问题，即验证位于 .Created 方法的末尾，它会访问文件以进行一些验证，然后再将其复制到目标位置。当我到达这一点时，如果文件很大并且仍在从其源复制的过程中，它会返回一个 io“文件已在使用中”错误。
我想要做的是完成所有初步代码，然后我希望线程“挂起”，直到文件的 .Changed 方法触发，表明文件已完成，因为我只捕获对最后访问过滤器。
【问题讨论】：
标签： c# multithreading filesystemwatcher
使用可以使用ManualResetEvent。 Created 方法可以完成它的工作，然后等待 Changed 事件发出 Created 方法可以继续的信号。
【讨论】：
我将使用生产者-消费者模式设置一个单独的线程，以监视项目是否出现在队列中。这些项目将代表文件更改，并包括文件路径和发生的更改类型等信息。您的FileSystemWatcher 事件处理程序只会将项目发布到队列中，并让消费者线程出列并处理信息。这将使您需要的处理与文件系统通知事件分离，从而更容易避免“文件正在使用”问题。
【讨论】：
这个问题是正常的，当其他进程忙于写入文件时，您通常无法打开文件。您需要等待，您无法预测何时完成。将文件的路径添加到列表中，并使用计时器清空该列表，定期重试操作。请注意逻辑，您正在使用线程，因此您需要使用锁来保护列表。
【讨论】：
请注意，NotifyFilters.LastAccess 并不意味着您会知道其他进程何时完成了该文件。它只是意味着您会在文件的上次访问时间发生更改时收到通知。
我通常采用 Brian Gideon 的生产者-消费者模式。这也使得过滤掉FileSystemWatcher 愉快分发的（典型的）多个Changed 事件变得容易。
（几乎）确定其他进程已完成文件的唯一方法是尝试获得对其的排他锁。但是，这并不总是足够的。我见过一个 FTP 服务器，它为它写的每个块关闭并重新打开文件 ;-)
还请注意，FileSystemWatcher 确实有一个内部缓冲区，用于缓冲从 Windows 获得的文件通知，但如果发生很多情况，该缓冲区可能会溢出。这又是创建生产者-消费者的原因。
我通常通过创建一个例程来修改这一点，该例程可以手动扫描监视的目录，然后偶尔运行一次。是的，投票;-)
在启动您的应用程序时使用此例程也很不错。文件可能在停机时已到达！
【讨论】：