我已经实现了一个应用程序，它使用 Java NIOWatchService来监视目录树中文件和文件夹的更改。在 Windows XP 上运行，所有文件系统更改都被拾取 - 除了通过在资源管理器中拖放将目录移动到受监视的树中。
拾取事件用于剪切和粘贴目录（ctrl+x、ctrl+v），而不是拖放（编辑- 请参阅下面的更新）。
我已经使用JPathWatch重新实现了解决方案，但是这也遇到了同样的问题。
我正在注册标准ENTRY_CREATE，ENTRY_DELETE并且在 Windows 上运行应用程序ENTRY_MODIFY时还使用了好奇的未充分记录的文件com.sun.nio.file.ExtendedWatchEventModifier来避免其他问题。
除了投票——我真的不想这样做——有人有什么想法吗？
更新
问题一般是移动文件 - 我误认为 ctrl+x/ctrl+v 工作。有关说明，请参见下面的解决方案。
编写测试用例证明最初的怀疑是不正确的——问题在于Windows 下的任何文件移动操作。
根本问题似乎是在ExtendedWatchEventModifier.FILE_TREE复制父目录但未移动时，在 Windows 上使用修饰符递归地监视所有子目录。
移动ENTRY_CREATE目录时，仅在父目录上注册，因此我的解决方案是手动删除FILE_TREE并递归监视目录。
有一个警告，这有点输/输的情况 -FILE_TREE首先使用的原因是允许监视目录树的递归删除。如果手动递归监视目录，则会在子目录上放置文件锁。这可以防止用户在不先删除子目录的情况下删除父目录。
使用FILE_TREE意味着仅在父文件夹上获得锁定，因此用户可以删除完整的树。
使用 JPathWatch 而不是 Java 7 NIO 会导致相同的行为：文件锁定和用户无法递归删除目录树。
最后一个可用的解决方案是使用 Apache Commons IO 的监控类的轮询方法，基于这个例子（但在 之后有一个额外的无限循环monitor.start()，因为这不会像暗示的那样阻塞。