Mac OS X 上的 kqueues：奇怪的事件顺序

Question

我使用 kqueues/kevent(2) 在单独的线程中监视文件的更改。 （我监视一个Python文件以进行重新解析）

我订阅如下：

EV_SET(&file_change, pyFileP, EVFILT_VNODE,
       EV_ADD | EV_CLEAR,
       NOTE_DELETE |  NOTE_WRITE | NOTE_EXTEND | 
               NOTE_ATTRIB | NOTE_LINK | NOTE_RENAME | NOTE_REVOKE,
       0, 0);

当我使用Vim写入文件“/tmp/somefile.py”时，我得到两个单独的kevent： 这些事件的标志（event.fflags）是：

NOTE_RENAME

并且

NOTE_DELETE | NOTE_LINK

我从未收到“NOTE_WRITE”事件！ 这似乎与 Vim 写入这些文件的方式有关，因为如果我这样做，

echo "sometext" >> /tmp/somefile.py

我确实会得到：

NOTE_WRITE|NOTE_EXTEND

事件。

奇怪，是吗？我还没有检查 Vim 源代码，但它一定做了一些奇怪的事情，或者它只是使用以这种方式实现的用户级函数？

我真的没想到会这样。这是一个已知问题，我只需要检查所有可能的事件，或者是否有一个已知的接口真正检查文件是否已被写入？

Answer 1

实际上发生的是 Vim 首先不会写入同一个文件
它可能会将其重命名为其他名称，然后创建另一个文件（链接）。
您可以通过执行以下操作来确认：

$ vim file -c wq

这将打开一个文件并写入它。现在检查 inode：

$ ls -i
30621217 file

再次用 Vim 写入文件并重新检查 inode：

$ vim file -c wq
$ ls -i
30621226 file

只是不同。这意味着第二个文件实际上是另一个文件
（链接到另一个 inode）具有相同的名称，并且旧的已取消链接。

许多编辑都这样做。我无法确认 Vim 到底为什么采取这种方法。
也许为了安全：如果您首先重命名文件并且出现问题
在写入新文件时，您仍然拥有旧文件。如果你开始写作
在文件上并且出现问题（即使有内存）你可能会丢失部分
它的。 也许。