我遇到以下情况：
稍微修改了一下，我注意到它在调试时工作正常。我在读取文件的行上设置了一个断点，因此增加了一点延迟。之后 - 读取文件并进行更改。
因此，似乎添加time.sleep(1)或以其他方式延迟执行就可以了。否则我收到过早的IN_CLOSE_WRITE事件。
我想知道在提交更改并且文件已关闭之后是，还是之前。在IN_CLOSE_WRITE之后似乎没有其他相关事件。与此同时，文档有点棘手：
使用IN_CLOSE_WRITE，因为如果发出相应文件的所有更改都安全地写入文件
我在常见问题解答中提交了关于措辞的错误报告，但与此同时我想就此问题获得一些额外的意见。这应该发生吗？什么是“道德上正确”的解决方法？
所有这一切都发生在Linux Mint 15 x64上。
答案 0 :(得分：4)
事实证明这种行为是not an anomaly：
正如我之前所说，我认为inotify的任务（因此Pyinotify报告）是在文件关闭时发出信号（更确切地说是文件描述符关闭时），但显然内核使用了缓冲区因此文件数据可能不会立即写入磁盘。有关更多详细信息，请参阅close（）函数的man（2）：
成功关闭并不能保证数据已成功保存到磁盘，因为内核会延迟写入。当流关闭时，文件系统刷新缓冲区并不常见。如果您需要确保数据是物理存储的，请使用fsync（2）。 （这取决于此时的磁盘硬件。）
您不能依赖
IN_CLOSE_WRITE来确定您的数据已完成写入磁盘。
换句话说，它不是一个过早的通知，它来自正确的时间;但操作系统的基本机制可以继续对该文件做一些事情。
答案 1 :(得分：0)
文档说“已关闭”：
$ man 7 inotify|grep IN_CLOSE_WRITE
IN_CLOSE_WRITE File opened for writing was closed (*).