Java File Watcher 无法识别文件更改

问题描述

我正在尝试使用 Java File Watcher 来侦听文件中的更改。当我使用 vim 编辑文件时，文件观察器会检测到更改。但是当我使用 sed 替换文件中的单词时，文件观察器无法识别更改。我可以看到修改日期是正确的。

watchService = FileSystems.getDefault().newWatchService();
Path parent = file.getParent();
parent.register(watchService,StandartWatchEventKinds.ENTRY_MODIFY
);

sed 命令看起来像这样：

sed -i 's/a/b/g' file.csv

sed 命令本身有效，文件实际上已更改，修改日期也已更改，但出于某种原因，火灾观察者没有

Java 版本 - openjdk 版本 1.8.0_222

更新

所以我已经开始工作了，一开始我尝试了一个 ansible 脚本，我使用了模块“replace”，但它没有用，因此我尝试使用上面提到的 sed 在本地更改文件，但没有成功。

现在我已经通过制作一个不同的 ansible 脚本让它工作了，在新脚本中，我使用 cp 命令将想要的文件复制到 tmp 文件，然后在 tmp 文件上使用“替换”模块，最后将 tmp 文件复制回想要的文件。
我不确定为什么会解决这个问题。

我还发现，将 ansible 的“复制”模块用于我上面描述的过程并没有帮助，使用 shell cp 购买它会触发文件观察器。

即使我已经解决了它，我也想听听您是否知道为什么使用 sed 进行更改时文件观察器不会触发

解决方法

许多语言实现了一些“文件观察者”监控功能。它通常归结为使用某些内核功能（例如 Linux 上的 inotify）。虽然这在本地文件系统上工作得很好（尽管对被监视的文件数量有一些限制），但它在远程安装的文件系统上经常失败。 This SO answer 很好地解释了这一点。

在我们的团队中，我们经常监控数百万个文件的更改/删除/创建，包括远程位置，但这依赖于轮询（以优化、简约的方式）和缓存。在实施此之前，我们尝试并查看了各种语言的其他选项（包括 inotify 和 watchdog），但意识到它们都无法可靠地检测到远程 NFS 上的更改。

一些提示，如果你想开始这样的事情：

stat 单个目录非常快，但它只检测某些更改（新文件/子目录、删除的文件/子目录）而不是文件/子目录的一些修改；
glob 约 10K 文件的模式可以比远程 NFS 上的 stat 文件快约 50 倍；
通常（但不总是）上次更改的文件最有可能再次更改：保留这些文件的“尾部”以进行快速检查，但会定期进行全面扫描。

file-watcher java java