5

我遇到以下情况：

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

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

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

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

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

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

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

4

2 回答 2

4

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

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

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

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

换句话说，这不是一个过早的通知，它来得正是时候；但是操作系统的底层机制可以继续对该文件执行某些操作。

于 2013-10-16T14:43:09.543 回答
1

文档说“已关闭”：

$ man 7 inotify|grep IN_CLOSE_WRITE
           IN_CLOSE_WRITE    File opened for writing was closed (*).
于 2013-10-13T12:17:44.880 回答