ListFile 处理器未检测到先前处理的文件的任何更改并重新处理它。仅供引用，我已经尝试了以下选项进行重新处理，并且只有最后提到的黑客有效。这是我在开发环境中运行的单节点 NiFi。
- 更新场景:ListFile 处理器未检测到文件内容更改并自动触发更新后(即使用 VIM 编辑器更新文件)
- 时间戳修改场景:使用 touch -c 命令更改文件时间戳会更改文件时间戳，但这也不会导致 ListFile 处理器自动触发。
- 停启动场景:如上所述更改文件后NiFi中整个进程组的停启动也不会引起ListFile处理器的触发。
- 等待子句:文件更改后等待足够长的时间也没有帮助 - 以防万一我们假设它会在延迟一段时间后自动触发。
- HACK:我能够触发 ListFile 处理器重新处理文件的唯一方法是以无害、幂等的方式更改 ListFile 处理器中“文件过滤器”的通配符表达式，例如从
.*test.*\.csv到test.*\.csv，反之亦然(即像这样来回重复重新处理)。
我们需要重新处理具有相同旧名称和修改数据的文件。请帮忙!
有时，如果上游/下游出现意外数据问题，甚至可能需要强制重新处理未修改的文件。请帮忙!
更新
仍然面临这种零星行为!当 ListFile 处理器无法响应文件更改时，只有重新启动 NiFi 才会有帮助。
最佳答案
这可能是延迟答复。 旧的列表处理器(例如ListFiles/ListFtp/ListSftp等)仅使用时间戳跟踪策略来识别更改的文件。处理器用于在其处理器状态中缓存最后看到的时间戳，并使用它来列出仅具有更大时间戳的文件。 然而，这种方法有很多缺陷。因此他们必须想出更好的策略，称为Entity Tracking 。这种方法提供了广泛的 文件更改的监控范围。它跟踪指定目录中每个文件的以下参数。
- 姓名
- 尺寸
- 上次修改时间戳
文件中的任何更改都会反射(reflect)在这些关键参数中。由于它们被缓存，任何差异都被视为更改，因此更改的文件会出现在成功的连接中。
关于apache-nifi - 尼菲 : ListFile Processor is not detecting file changes sometimes，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51088169/