使用FileSystemWatcher检测移动的文件

2018-06-20 18:05:43

我意识到FileSystemWatcher不提供Move事件，相反它会为同一个文件生成一个单独的Delete和Create事件。（FilesystemWatcher正在监视源文件夹和目标文件夹）。

然而，我们如何区分真正的文件移动和随机创建一个恰好与最近删除的文件具有相同名称的文件？

FileSystemEventArgs类的某种属性，例如“AssociatedDeleteFile”，如果它是移动的结果，则指定删除的文件路径，否则为NULL。但当然这不存在。

我也明白，FileSystemWatcher在基本的文件系统级别上运行，因此“移动”的概念可能只对更高级别的应用程序有意义。但是，如果是这样的话，人们会推荐什么样的算法来处理我的应用程序中的这种情况？

根据反馈进行更新：

FileSystemWatcher类看起来只是将文件移动为两个不同的事件，即删除原始文件，然后在新位置创建一个文件。

不幸的是，这些事件之间没有提供“链接”，因此如何区分文件移动和正常的删除或创建并不明显。在操作系统级别，特别处理移动，您可以几乎瞬间移动1GB文件。

有几个答案建议使用文件散列来在事件之间可靠地标识它们，我会采取这种方法。但是如果有人知道如何更简单地发现一个动作，请留下一个答案。

根据文档：

通用文件系统操作可能引发多个事件。例如，当文件从一个目录移动到另一个目录时，可能会引发几个OnChanged和一些OnCreated和OnDeleted事件。移动文件是一项复杂的操作，由多个简单操作组成，因此引发多个事件。

所以如果你想要非常小心地检测移动，并且使用相同的名字不够好，你将不得不采用某种启发式的方法。例如，使用文件名，大小，上次修改时间等来创建源文件夹中的文件的“指纹”。当您看到任何可能表示移动的事件时，请检查新文件的“指纹”。

据我了解， Renamed事件是为文件被移动...？

我的错误 - 文档明确指出，只有移动文件夹中的文件在剪切和粘贴操作中才会被视为“重命名”：

操作系统和FileSystemWatcher对象将剪切并粘贴操作或移动操作解释为文件夹及其内容的重命名操作。如果您将包含文件的文件夹剪切并粘贴到正在监视的文件夹中，FileSystemWatcher对象只会将该文件夹报告为新文件夹，但不会报告其内容，因为它们基本上只被重命名。

它还说移动文件：

我会冒险猜测'移动'确实不存在，所以你真的只需要寻找'删除'，然后将该文件标记为可能'可能移动'的文件，然后如果你看到一个'创造'它不久之后，我想你可以认为你是正确的。

你有一个随机文件创作案例影响你的移动检测？

链接地址: http://www.djcxy.com/p/58337.html