pyinotify 过早的 IN_CLOSE_WRITE 通知

Question

我遇到以下情况：

• pyinotify 监视文件中的 IN_CLOSE_WRITE 事件
• 我更改了文件中的内容并保存
• 事件被触发
• 我阅读了文件，发现它没有任何变化

稍微修改了一下之后，我注意到它在调试时运行良好。我在读取文件的行上设置了一个断点，从而增加了一点延迟。之后 - 文件被读取并且更改就在那里。

因此，添加 atime.sleep(1)或以其他方式延迟执行似乎可以解决问题。否则我会收到一个过早的 IN_CLOSE_WRITE 事件。

我想知道该事件是在提交更改并关闭文件之后还是在此之前触发。IN_CLOSE_WRITE 之后似乎没有其他相关事件。同时，文档有点棘手：

使用 IN_CLOSE_WRITE 因为如果发出，则相应文件上的所有更改都会安全地写入文件中

我提交了关于常见问题解答中措辞的错误报告，但与此同时，我想就此事获得一些额外的意见。这是应该发生的吗？什么是“道德正确”的解决方法？

所有这些都发生在 Linux Mint 15 x64 上。

Answer 1

事实证明，这种行为并不是异常：

正如我之前所说，我认为 inotify 的任务（因此正如 Pyinotify 所报告的那样）是在文件关闭时向您发出信号（更准确地说，当文件被其文件描述符关闭时），但显然内核使用缓冲区，因此文件数据可能不会立即写入磁盘。更多详细信息请参见 close() 函数的 man(2)：

成功关闭并不能保证数据已成功保存到磁盘，因为内核会延迟写入。文件系统在流关闭时刷新缓冲区的情况并不常见。如果需要确保数据是物理存储的，请使用 fsync(2)。（此时这将取决于磁盘硬件。）

最重要的是，您不能依赖IN_CLOSE_WRITE于确定您的数据已完成写入磁盘。

换句话说，这不是一次过早的通知，而是恰逢其时；但操作系统的底层机制可以继续对该文件执行某些操作。