inotify - 使用 pyinotify 过早发出 IN_CLOSE_WRITE 通知

Question

我遇到以下情况:

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

对此进行了一些修改，我发现在调试时它工作得很好。我在读取文件的行上设置了一个断点，从而增加了一点延迟。之后 - 文件被读取并且更改就在那里。

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

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

use IN_CLOSE_WRITE because if emitted the all changes on the appropriate file are safely written inside the file

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

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

Answer 1

原来这个行为是not an anomaly :

As I said previously I think that the mission of inotify (and therefore as reported by Pyinotify) is to signal you when a file is closed (more precisely when it is closed by its file descriptor), but obviously the kernel uses buffers and so the file data may not be written on disk immediately. For more details see the man (2) of the close() function:

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)

你不能依赖的底线IN_CLOSE_WRITE确保您的数据已完成写入磁盘。

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