IN_MOVE_TO 是不是直接跟随 inotify 中的 IN_MOVE_FROM？

Posted 2023-02-17

【中文标题】IN_MOVE_TO 是不是直接跟随 inotify 中的 IN_MOVE_FROM？

【英文标题】：Does IN_MOVE_TO directly follow a IN_MOVE_FROM in inotify?IN_MOVE_TO 是否直接跟随 inotify 中的 IN_MOVE_FROM？

【发布时间】：2016-09-30 11:40:13

【问题描述】：

移动文件时，inotify 将发出IM_MOVE_FROM、IN_MOVE_TO 或两者。事件中有一个 cookie 字段，其值允许我们确定链接的事件。

未指定的是链接的MOVE 事件的顺序以及MOVE_TO 是否总是直接跟随链接的MOVE_FROM（如果两者都发出）。

他们之间可能还有其他事件吗？

如果是，是否有多个 MOVE 事件对混在一起？

【参考方案1】：

我知道这不是对您的确切问题的权威答案，但想分享我们在 watchman code 中所做的事情，它在大量具有大量文件和高变化率。

我们防御性地做出以下假设：

MOVE_FROM 位于 MOVE_TO 之前 我们可能得不到 MOVE_FROM 我们可能得不到 MOVE_TO

因为我们有点悲观，并且 inotify 文档中的措辞模棱两可，我们将 cookie -> 移动信息记录在地图中，这样我们就不会依赖 MOVE_TO 直接在 MOVE_FROM 之后出现。它也有点复杂，因为 MOVE_FROM 可能是一次读取时适合您的读取缓冲区的最后一个数据，而 MOVE_TO 可能是后续读取的第一个数据。

每当我们消耗了 inotify 流中的所有可用数据时，我们都会清除映射（例如：非阻塞读取返回 0 字节）。该地图中的任何内容都属于上述 (3.) 类别，并且将来不会显示。

【讨论】：

感谢您的回答。这很有帮助。这并不容易，但是您处理它的方式可以涵盖所有情况。当您处理完事件并且地图不为空时，您是否执行非阻塞读取以检查是否还有更多事件？你如何确定 MOVE_TO 是否缺席？在非常密集的 inotify 活动（创建/删除 10000 个文件）的情况下，您可能需要等待很长时间，直到发生读取 0 事件。有超时吗？如果我们可以假设 MOVE_TO 立即跟随 MOVE_FROM 如果存在（最终在下一个读取事件批次中），那就更简单了。

我链接到了代码，这样您就可以看到我们为自己做了什么。 Watchman 的模型是不直接跟踪重命名，所以理想情况下我们会忽略这一点。但是，我们必须做一些基本的跟踪来了解 inotify 何时单方面更改了监视描述符 -> 名称映射。