我遇到以下情况：
- pyinotify 监视文件中的 IN_CLOSE_WRITE 事件
- 我更改文件中的某些内容并保存
- 事件被触发
- 我阅读了该文件，发现它没有任何更改
经过一番修改后，我注意到在调试时它工作得很好。我在读取文件的行上设置了一个断点，从而增加了一点延迟。之后 - 文件被读取并且更改就在那里。
所以，似乎添加一个time.sleep(1)，或者以其他方式延迟执行就可以了。否则我会收到过早的 IN_CLOSE_WRITE 事件。
我想知道事件是否被触发after提交更改并关闭文件，或者before那。 IN_CLOSE_WRITE之后似乎没有其他相关事件。同时，文档有点棘手：
使用 IN_CLOSE_WRITE 因为如果发出the all对相应文件的更改会安全地写入文件内
我提交了一份关于常见问题解答中措辞的错误报告，但与此同时，我想获得有关此事的一些额外意见。这应该发生吗？解决这个问题的“道德上正确”的方法是什么？
所有这一切都发生在 Linux Mint 15 x64 上。
事实证明，这种行为是并非异常 https://github.com/seb-m/pyinotify/issues/55:
正如我之前所说，我认为 inotify 的任务（因此正如 Pyinotify 所报告的那样）是在文件关闭时向您发出信号（更准确地说，当文件被其文件描述符关闭时），但显然内核使用缓冲区，因此文件数据可能不会立即写入磁盘。更多详细信息请参见 close() 函数的 man(2)：
成功关闭并不能保证数据已成功保存到磁盘，因为内核会延迟写入。文件系统在流关闭时刷新缓冲区的情况并不常见。如果需要确保数据是物理存储的，请使用 fsync(2)。 （此时这将取决于磁盘硬件。）
你不能依赖的底线IN_CLOSE_WRITE确保您的数据已完成写入磁盘。
换句话说，这不是一次过早的通知，而是恰逢其时；但操作系统的底层机制可以继续对该文件执行某些操作。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
