验证ftp是否完整？

我得到了一个应用程序，它在一个文件夹上连续轮询。一旦任何文件通过ftp传输到该文件夹，应用程序必须将该文件移动到其他文件夹进行处理

在这里，我们没有任何选项来验证ftp是否完整

技术论坛建议使用一个命令“lsof”。它有一个文件描述列，提供文件状态

因为这是一个免费的bsd命令，在旧版本的linux中不存在，所以我想澄清一下这个命令的用法

你们能告诉我们你们在文件验证方面的经验吗？还有其他的解决方案吗

此外，使用此实用程序是否存在任何风险

提前感谢你的帮助

谢谢，

---

马修·李朱（Mathew Liju）

我们以前用过很多不同的方法

方法一：

如果您可以控制发送文件的过程，请让它先发送文件本身，然后再发送sentinel文件。例如，发送真正的文件

“contracts.doc”

，后跟一个字节的

“contracts.doc.sentinel”

然后让侦听器进程注意sentinel文件。创建其中一个文件时，应处理等效的数据文件，然后同时删除这两个文件

任何超过一天的数据文件都没有相应的sentinel文件，请将其删除-这是一次失败的传输

方法二：

密切关注文件本身（特别是上次修改日期/时间）。仅处理过去修改时间超过

N

分钟的文件。这会增加处理文件的延迟，但您通常可以确定，如果一个文件在五分钟内没有写入（例如），它就完成了

结论:

这两种方法过去都被我们成功地使用过。我更喜欢第一个，但当我们不允许更改发送文件的过程时，我们不得不使用第二个

---

第一种方法的优点是，当sentinel文件出现时，您知道该文件已准备就绪。使用<代码> LSOF（我假设您处理任何进程未打开的文件准备处理）和时间戳，FTP可能在中间崩溃，您可能正在处理半个文件。

这类问题通常有三种方法。

提供一个信号文件，以便在传输文件时，发送一个附加文件以标记传输完成

在该目录中的日志文件中添加一个条目，以指示传输已完成（这实际上仅在有一个对等方更新该目录时有效，以避免并发问题）

解析文件以确定完整性。e、 g.文件是以长度字段开头，还是明显不完整？e、 g.解析不完整的XML文件将由于缺少结束元素而导致解析错误。根据文件的大小和格式，这可能很简单，也可能非常耗时

lsof

可能是一个选项，尽管您已经确定了Linux可移植性问题。如果使用此选项，请注意-F选项，该选项可格式化输出，以适合其他程序处理，而不是人类可读

---

编辑：Pax确定了我忘记的第四种（！）方法-使用文件的时间戳在一段时间内没有更新的事实。

还有第五种方法。您还可以检查FTP会话是否仍处于活动状态。如果每个对等方都有自己的ftp用户帐户，这将起作用。只要用户没有从FTP注销，就假定文件不完整。

谢谢您，帕克斯。我们对第一种方法也有类似的问题，因为企业不想改变流程。我决定采用第二种方法。谢谢Brian的评论。但输入文件解析是一项乏味的任务，因为它是格式化的，业务部门不同意对流程进行更改。