为什么inotify事件会触发多次

这个问题来自于我对Stackoverflow提出的另一个问题。我使用的守望者 -同样的问题也适用于Incron -监视文件夹，更改和默默离开松鼠这些更改的Dropbox其子文件夹。

我监视write_close事件-- IN_CLOSE_WRITE为此。最初，我正在观看modify事件，即IN_MODIFY。在此过程中，我发现写入大型文件时会触发多次。听起来很公平，所以我转而去，IN_CLOSE_WRITE因为我觉得假设一个给定的文件只会出现一次是很合理的。

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

我现在通过在执行其他任何操作之前使同步脚本休眠10秒钟来解决此问题，然后在尝试Dropbox同步之前检查相关文件是否仍然存在。之所以有效，是因为在第二次迭代中文件丢失并且脚本刚刚终止。

充其量听起来好像很黑。也许这不是一个糟糕的技巧，但我更希望理解-为什么连IN_CLOSE_WRITE事件都发生不止一次？

一些其他信息

• 检查以确保没有多个观察程序实例在运行。

来自的输出 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遇到了完全相同的问题。我从通过执行的批处理脚本启动Watcher守护程序/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]。

我不确定，但是很可能第一个write_close将文件属性写入其中，例如创建时间，并且只有在此之后才写入实际数据。实际上，rsync会创建一个临时文件，当所有操作完成后，它将临时文件移至同一文件夹中的实际文件，因此使用rsync时通常已经创建了易于监视的文件，而move是原子操作。另一方面，在inotify中有一个被调用的东西，可能是使用它可以在第一个修改消息上触发一些东西，并且如您所建议的，在开始操作之前要睡眠一段合理的时间。我现在正在对此进行挖掘，当我发现新内容时会进行更新。 /superuser/1133642/traceing-the-moment-when-file-is-completely-copied-to-samba-share-with-inotify

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

听起来您好像注意到了在同一文件上触发多个文件的事件，这不是我能够复制的东西-对于临时文件只会发生一次，对于原始文件只会发生一次。

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