APPE FTP命令传输完成检测服务器端

Posted 2023-02-17

【中文标题】APPE FTP命令传输完成检测服务器端

【英文标题】：APPE FTP command transfer completion detection serverside

【发布时间】：2012-05-11 14:27:06

【问题描述】：

我有一个通过 FTP 处理传入文件的服务。

在我安装 Proftpd 的 Debian 服务器上，我使用 iNotify 事件来确定文件传输何时完成并且我可以开始使用它。

一旦不再写入文件，就会触发该事件。

在我发现新的尼康 D4 相机和 WT-5 无线发射器使用 APPE FTP 命令发送文件之前，这一直很有效。

从我读到的内容看来，APPE FTP 命令以数据块的形式发送文件，这些文件在第一个块创建文件后附加到服务器上的现有文件中。

但是，这会导致多个 iNotify 事件被触发，因为文件被多次而不是一次写入，直到连接关闭。

由于文件是在文件完成之前处理的，因此一旦处理就会导致错误。而且我总是在处理后删除文件。

由于我的这项服务在处理传入文件时必须保持快速，我真的很喜欢这个带有 iNotify 的解决方案，并且真的不想计时文件大小是否保持不变 n 秒或任何确定文件传输是否正常的时间完成。

我的问题是：有什么方法可以确定文件传输是否实际完成，而无需检查文件大小或比较上次修改日期？

我试图在 proftpd 中找到一种方法来执行此操作，但无济于事。

xferlog 指出同一个文件已完成多次：

Fri May 11 14:15:41 2012 2 host-95-199-17-243.mobileonline.telia.com 131072 /var/app/incoming/file.JPG b _ i r auser ftp 0 * c
Fri May 11 14:15:43 2012 2 host-95-199-17-243.mobileonline.telia.com 262144 /var/app/incoming/file.JPG b _ i r auser ftp 0 * c
Fri May 11 14:15:47 2012 3 host-95-199-17-243.mobileonline.telia.com 385624 /var/app/incoming/file.JPG b _ i r auser ftp 0 * c

末尾的c表示传输完成。

因此，如果我必须检查每个传入文件的文件是否实际完成，这将意味着对实际完成的文件造成不必要的延迟。

看起来这应该不是一个不寻常的问题，但找不到任何相关信息。

有什么想法吗？

【问题讨论】：

你在 inotify 中监听哪个事件？

我正在收听 IN_CLOSE_WRITE。

【参考方案1】：

不幸的是，这种用例没有好的答案。问题是只有 FTP 客户端 知道何时将数据上传到服务器，而 FTP 客户端 知道“文件”何时完成。该协议根据字节流运行。而且，正如您使用APPE 命令所注意到的那样，除了一次上传之外，还可以在块 中进行上传。请注意，当 FTP 客户端使用REST 命令后跟STOR 时，可能会发生相同的行为。 （SFTP，为了比较，仅允许按块上传，即它使用：OPEN，WRITE，WRITE，WRITE，...， CLOSE，更紧密地映射到用于写入文件的 Unix 系统调用。）

您甚至可能想使用QUIT 命令作为触发器，以了解该客户端已完成将其所有块上传到您的服务器。假设您的 FTP 客户端一次只打开一个 FTP 会话，这可能会起作用。

根据您的具体用例/需求，可能会找到其他解决方案；如果您愿意，请随时给我发电子邮件。

希望这会有所帮助！

【参考方案2】：

还要处理检测 JPG 传输结束并使用可以集成到脚本中的解决方案：

Catching error: Corrupt JPEG data: premature end of data segment

检查JPEG数据是否完整的一个简单方法是分别检查FF D8和FF D9的前两个字节。这两个字节分别标识 JPEG 文件的开始和结束。

或者使用 ImageMagick http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=8483

希望这可能对 D5 有所帮助；） 马修