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