为什么 inotify 事件触发不止一次

Question

这个问题来自我在Stackoverflow 上提出的另一个问题。我正在使用Watcher - 同样的问题也适用于Incron - 来监视文件夹及其子文件夹的更改，并悄悄地将这些更改转移到 Dropbox。

我监视write_close事件 - IN_CLOSE_WRITE- 出于这个目的。本来我是在看modify事件，即IN_MODIFY。虽然这行得通，但我发现在写入大文件时，它会触发不止一次。这听起来很公平，所以我改用了，IN_CLOSE_WRITE因为我觉得假设对于给定的文件它只会发生一次是合理的。

然而，事实并非如此。即使对于在 Nano 中创建的非常小的文本文件（只有一个字符），该事件也会发生两次。当同一个文件在 Dropbox 上同步两次时，这充其量会导致不必要的流量。在我自己的情况下，它会导致灾难，因为在第一个事件中我执行同步然后删除服务器端文件。结果 - 在第二个事件中，Dropbox 侧文件变为 0 字节文件。

我现在正在处理这个问题，让我的同步脚本在我做任何其他事情之前休眠 10 秒，然后在尝试 Dropbox 同步之前检查有问题的文件是否仍然存在。这是有效的，因为在第二次迭代时文件丢失并且脚本刚刚终止。

这听起来充其量是骇人听闻的。也许不是一个糟糕的黑客，但我更愿意理解 - 为什么甚至IN_CLOSE_WRITE事件发生不止一次？

---

一些附加信息

• 检查以确保没有多个 watcher 实例正在运行。

输出来自 ps ax|grep watcher.py

23880 ?        Sl     0:01 python /usr/local/bin/watcher.py restart
24977 pts/0    S+     0:00 grep --color=auto watcher.py

文件系统是ext4. 我应该提到，我遇到了与 Incron 完全相同的问题。我从通过/etc/rc2.d. Incron OTH 通过其默认apt-get install incron安装启动，我没有任何干扰。

---

我的watcher.ini文件的本质如下所示。

[DEFAULT]
logfile=/var/log/watcher.log
pidfile=/var/run/watcher.pid

[job1]
watch=/path/to/watch

events=write_close
excluded=
recursive=true
autoadd=true

command=/home/datastore.php $filename

我将datastore.php脚本简化为基本要素，以验证它是否在没有任何杂乱的 Dropbox 上传 + 源删除代码的情况下启动了两次。

#! /usr/bin/php
<?php
file_put_contents('/tmp/watcher',$argv[1],FILE_APPEND);

?>

然后我在有问题的路径上创建了一个小文件，然后检查了/tmp/watcher. 问题仍然存在 - 该文件仍然有两个连续的$argv[1].

Answer 1

我没有足够的代表将其作为评论发布，但是您确定没有创建临时的、可能隐藏的文件吗？inotifywait我在多次触发时遇到了类似的问题，但我意识到这是因为 vim 在编辑时会创建一个 .swp 文件，这会在关闭时触发一个事件。它还会从原始文件中获取关闭事件。

听起来您好像注意到事件在同一个文件上触发了多个文件，但这不是我能够重现的东西——这种情况只会在临时文件中发生一次，在原始文件中只会发生一次。

我尝试使用 nano 进行快速测试，我认为它根本不会创建临时文件（至少对于少数字符情况），但是您的设置中是否还有其他内容可以依赖类似的行为？

Answer 2

我不确定，但很可能第一个 write_close 将文件属性写入其中，例如创建时间，并且只有在此之后才写入实际数据。事实上，rsync 创建一个临时文件，当一切完成后，它将临时文件移动到同一文件夹中的实际文件，因此很容易监视在使用 rsync 时通常创建的文件，并且移动是一个原子操作。另一方面，inotify 中有一个叫做一次性的东西，可能使用它我们可以在第一个修改消息上触发一些东西，并且正如您建议的在开始操作之前睡眠合理的时间。我现在正在挖掘这个，当我发现任何新东西时会更新。 https://superuser.com/questions/1133642/traceing-the-moment-when-file-is-completely-copied-to-samba-share-with-inotify