Inotify 等待复制脚本损坏图像

Posted

技术标签:

【中文标题】Inotify 等待复制脚本损坏图像【英文标题】:Inotify wait Copy Script Corrupting Images 【发布时间】: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 尝试在照片完全传输之前发送照片?有人有解决方案吗?

【问题讨论】:

见***.com/questions/4231243/inotify-with-nfs。但是,您可能会遇到与 NFS 无关的问题,因为生产者在首次创建文件后可能仍在写入文件,这意味着您正在复制在复制过程中发生更改的文件。通常,您需要生产者确保文件在写入整个文件之前不会出现在其“预期”名称下,例如write_to_file tmpname && mv tmpname realname。这样一来,您就知道realname 一经创建就完成了。 【参考方案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 事件并检查是否对您有帮助

以上是关于Inotify 等待复制脚本损坏图像的主要内容,如果未能解决你的问题,请参考以下文章

使用 inotify 通知新文件

inotify同步脚本

inotify工具介绍及实时复制实践

使用 Inotify 检测复制操作

文件复制工具--rsync

在后台运行 inotify 脚本