Inotify 等待复制脚本损坏图像答案

【问题标题】：Inotify wait Copy Script Corrupting ImagesInotify 等待复制脚本损坏图像
【发布时间】：2018-07-02 16:37:19
【问题描述】：

所以我使用 inotifywait 运行了这个脚本。一台服务器将图像放入位于 /var/nfs/device_images 的主机服务器上的 NFS 文件夹中。（chmod 在工作文件夹上为 777）然后主机服务器将其移动到 python 脚本的工作目录中。

inotifywait -m /var/nfs/device_images -e create -e moved_to | while read path action file; do cp /var/nfs/drvie_images/$file /home/samuel/programname/images/$file; done

它工作，有点。文件本身传输，但它已损坏。似乎 inotifywait 尝试在照片完全传输之前发送照片？有人有解决方案吗？

【问题讨论】：

见stackoverflow.com/questions/4231243/inotify-with-nfs。但是，您可能会遇到与 NFS 无关的问题，因为生产者在首次创建文件后可能仍在写入文件，这意味着您正在复制在复制过程中发生更改的文件。通常，您需要生产者确保文件在写入整个文件之前不会出现在其“预期”名称下，例如write_to_file tmpname && mv tmpname realname。这样一来，您就知道realname 一经创建就完成了。

标签： python linux nfs inotifywait

【解决方案1】：

create 事件会在文件被完全写入之前被创建，从而看起来像图像已损坏

解决此问题的一种方法是使inotifywait 仅侦听move 事件并强制填充/var/nfs/device_images 的服务器在临时目录中创建文件，并在完成时将其移至/var/nfs/device_images。

您可以为大多数用于抓取文件的实用程序指定temp 目录，例如rsync / wget

【讨论】：

您知道在使用内置 nfs 时是否有任何方法可以指定 tmp 目录（使用 export -a 应用的配置）？但是谢谢，很好的信息，我让它在复制前等待 5 秒，但我不喜欢那样做。
你显然不能从 nfs 客户端做很多事情。如果您无法控制 nfs 服务器如何在 nfs 目录中填充图像，那么我的建议是使用 inotofywait 的 close_write 事件并检查是否对您有帮助