FTP 使用 Apache 下载的数据截断

Question

使用来自 commons-net:commons-net:3.6 的 Apache FTP 客户端，我正在使用

从我们的 FTPS 服务器读取文件

FTPClient#retrieveFile("/OUT/somefile.xml", someBAOS)

通常情况下，一切正常，但有时文件会被截断。

这是一切正常时的协议：

< 220 ProFTPD 1.3.5a Server (someserver) [::ffff:...]
> AUTH TLS
< 234 AUTH TLS successful
> PBSZ 0
< 200 PBSZ 0 successful
> PROT P
< 200 Protection set to Private
> USER someuser
< 331 Password required for someuser
> PASS ***
< 230 User someuser logged in
> TYPE I
< 200 Type set to I
> PASV
< 227 Entering Passive Mode (...).
> RETR /OUT/somefile.xml
< 150 Opening BINARY mode data connection for /OUT/somefile.xml (4769503 bytes)
< 226 Transfer complete

当文件被截断时，记录的是较小的大小：

< 150 Opening BINARY mode data connection for /OUT/somefile.xml (2569402 bytes)

截断偶尔发生。在下一次下载时，一小时后，一切都恢复正常。我们非常确定该文件在此期间没有更改。

日志文件是使用 SocketClient#addProtocolCommandListener 生成的，我很确定更改后的大小不是来自我的侦听器。我猜，文本是由 FTP 服务器生成并按原样转储的。 有人可以确认文件大小确实来自服务器（而不是由 Apache 客户端添加）吗？

有趣的是，下载的截断文件有 2602133 字节（而且我很确定，没有通过文本转换或类似方式添加的 \r；首先，我们进行转换；其次，差异为 31371字节，那里有 56577 行）。

最可能的解释是有人在此期间更改了文件，但服务器日志清楚地表明当时没有其他人。

知道如何找出发生了什么吗？

结果

我有更多日志清楚地显示在出现问题时左右有上传。同时，日志声称没有时间重叠。无论如何，确认 150 ... 行直接来自服务器，毫无疑问，并发访问是罪魁祸首。

Answer 1

留言

< 150 Opening BINARY mode data connection for /OUT/somefile.xml (2569402 bytes)

来自服务器，即提供文件的服务器只能看到长度为 2569402 字节的文件。最可能的原因（不知道此处涉及的实际系统）是您尝试下载的文件当前已创建。这就是它在几分钟后工作的原因，因为文件创建已完成。

这是一个常见问题，有不同的解决方案：

创建一个 lock-file 具有定义的前缀或后缀的同名文件，您可以检查它是否存在，如果不存在则只执行下载。
检查大小一段时间，只有在一段时间内大小没有变化时才尝试下载。
使用临时名称或将文件创建到不同的目录中，然后rename/move将其添加到目标名称和目的地

正如我所说，我认为这不是您的客户端的问题，服务器显然报告了错误的长度，所以问题的原因肯定在那里。

Answer 2

服务器在建立数据连接后立即发送150 Opening...消息，即数据传输开始时。这意味着消息包含数据传输开始时从服务器角度来看的文件大小。这意味着文件在传输过程中没有被截断，而是比您在服务器端预期的要小。

由于使用了二进制模式，因此在服务器端不会更改行尾。鉴于您获得的实际下载大小大于服务器报告的大小但小于您的预期，很可能在下载运行.[=11= 时服务器端发生了一些文件更改。 ]

FTP 使用 Apache 下载的数据截断

Data truncation from FTP download using Apache

java

apache

ftp

ftp-client

file

结果