Apache Commons Net FTP 正在上传损坏的文件

发布于 2024-09-13 20:30:10 字数 3012 浏览 0 评论 0原文

我正在尝试使用 Apache Commons Net 进行 FTP 文件传输。

问题是文件间歇性到达服务器时已损坏。我所说的“损坏”是指 WinRAR 告诉我 ZIP 文件有一个“存档意外结束”。有时文件完全是空的。我注意到对于较大的文件(100kb+)来说这种情况更常见,但是对于小文件(20kb)也会发生这种情况。

我知道上传的源 zip 文件是有效的,并且只有 243kb。

我没有从代码中得到任何错误/异常。

下面是正在执行的代码:

int CON_TIMEOUT = (int) TimeUnit.SECONDS.toMillis(20); // fail if can't connect within 20 seconds
int LIVE_TIMEOUT = (int) TimeUnit.MINUTES.toMillis(5); // allow up to 5 minutes for data transfers

FTPClient client = new FTPClient();
client.setConnectTimeout(CON_TIMEOUT);
client.setDataTimeout(LIVE_TIMEOUT);
client.connect(host);
client.setSoTimeout(LIVE_TIMEOUT);
client.login(user, pass);
client.changeWorkingDirectory(dir);
log("client ready");

File file = new File(filePath);
String name = new Date().getTime() + "-" + file.getName();

InputStream fis = null;
try
{
    fis = new FileInputStream(file);
    if (!client.storeFile(name, fis))
        throw new RuntimeException("store failed");
    log("store " + name + " complete");
}
finally
{
    IOUtils.closeQuietly(fis);
    try
    {
        client.logout();
        log("logout");
    }
    catch (Throwable e)
    {
        log("logout failed", e);
    }
    try
    {
        client.disconnect();
        log("disconnect");
    }
    catch (Throwable e)
    {
        log("disconnect failed", e);
    }
}

和一些日志:

2010-08-10 21:32:38 client ready
2010-08-10 21:32:49 store 1281439958234-file.zip complete
2010-08-10 21:32:49 logout
2010-08-10 21:32:49 disconnect
2010-08-10 21:32:50 client ready
2010-08-10 21:33:00 store 1281439970968-file.zip complete
2010-08-10 21:33:00 logout
2010-08-10 21:33:00 disconnect
2010-08-10 21:33:02 client ready
2010-08-10 21:33:11 store 1281439982234-file.zip complete
2010-08-10 21:33:11 logout
2010-08-10 21:33:11 disconnect
2010-08-10 21:33:15 client ready
2010-08-10 21:33:25 store 1281439995890-file.zip complete
2010-08-10 21:33:26 logout
2010-08-10 21:33:26 disconnect
2010-08-10 21:33:27 client ready
2010-08-10 21:33:36 store 1281440007531-file.zip complete
2010-08-10 21:33:36 logout
2010-08-10 21:33:36 disconnect
2010-08-10 21:33:37 client ready
2010-08-10 21:33:48 store 1281440017843-file.zip complete
2010-08-10 21:33:48 logout
2010-08-10 21:33:48 disconnect
2010-08-10 21:33:49 client ready
2010-08-10 21:33:59 store 1281440029781-file.zip complete
2010-08-10 21:33:59 logout
2010-08-10 21:33:59 disconnect
2010-08-10 21:34:00 client ready
2010-08-10 21:34:09 store 1281440040812-file.zip complete
2010-08-10 21:34:09 logout
2010-08-10 21:34:09 disconnect
2010-08-10 21:34:10 client ready
2010-08-10 21:34:23 store 1281440050859-file.zip complete
2010-08-10 21:34:24 logout
2010-08-10 21:34:24 disconnect
2010-08-10 21:34:25 client ready
2010-08-10 21:34:35 store 1281440065421-file.zip complete
2010-08-10 21:34:35 logout
2010-08-10 21:34:35 disconnect

请注意,所有这些都在 15 秒内完成,并且服务器上的所有生成文件都已损坏。

我也测试过,没有设置任何超时,问题仍然出现。

I'm trying to use Apache Commons Net for FTP file transfers.

Problem is files are intermittently arriving at the server corrupt. By 'corrupt' I mean that WinRAR tells me a ZIP file has an 'Unexpected end of archive'. Sometimes the files are completely empty. I have noticed that this happens more for larger files (100kb+), however does happen for small files too (20kb).

I know for a fact that the source zip file being uploaded is valid, and is only 243kb.

I do not get any errors/exceptions from the code.

Here's the code being executed:

int CON_TIMEOUT = (int) TimeUnit.SECONDS.toMillis(20); // fail if can't connect within 20 seconds
int LIVE_TIMEOUT = (int) TimeUnit.MINUTES.toMillis(5); // allow up to 5 minutes for data transfers

FTPClient client = new FTPClient();
client.setConnectTimeout(CON_TIMEOUT);
client.setDataTimeout(LIVE_TIMEOUT);
client.connect(host);
client.setSoTimeout(LIVE_TIMEOUT);
client.login(user, pass);
client.changeWorkingDirectory(dir);
log("client ready");

File file = new File(filePath);
String name = new Date().getTime() + "-" + file.getName();

InputStream fis = null;
try
{
    fis = new FileInputStream(file);
    if (!client.storeFile(name, fis))
        throw new RuntimeException("store failed");
    log("store " + name + " complete");
}
finally
{
    IOUtils.closeQuietly(fis);
    try
    {
        client.logout();
        log("logout");
    }
    catch (Throwable e)
    {
        log("logout failed", e);
    }
    try
    {
        client.disconnect();
        log("disconnect");
    }
    catch (Throwable e)
    {
        log("disconnect failed", e);
    }
}

and some logs:

2010-08-10 21:32:38 client ready
2010-08-10 21:32:49 store 1281439958234-file.zip complete
2010-08-10 21:32:49 logout
2010-08-10 21:32:49 disconnect
2010-08-10 21:32:50 client ready
2010-08-10 21:33:00 store 1281439970968-file.zip complete
2010-08-10 21:33:00 logout
2010-08-10 21:33:00 disconnect
2010-08-10 21:33:02 client ready
2010-08-10 21:33:11 store 1281439982234-file.zip complete
2010-08-10 21:33:11 logout
2010-08-10 21:33:11 disconnect
2010-08-10 21:33:15 client ready
2010-08-10 21:33:25 store 1281439995890-file.zip complete
2010-08-10 21:33:26 logout
2010-08-10 21:33:26 disconnect
2010-08-10 21:33:27 client ready
2010-08-10 21:33:36 store 1281440007531-file.zip complete
2010-08-10 21:33:36 logout
2010-08-10 21:33:36 disconnect
2010-08-10 21:33:37 client ready
2010-08-10 21:33:48 store 1281440017843-file.zip complete
2010-08-10 21:33:48 logout
2010-08-10 21:33:48 disconnect
2010-08-10 21:33:49 client ready
2010-08-10 21:33:59 store 1281440029781-file.zip complete
2010-08-10 21:33:59 logout
2010-08-10 21:33:59 disconnect
2010-08-10 21:34:00 client ready
2010-08-10 21:34:09 store 1281440040812-file.zip complete
2010-08-10 21:34:09 logout
2010-08-10 21:34:09 disconnect
2010-08-10 21:34:10 client ready
2010-08-10 21:34:23 store 1281440050859-file.zip complete
2010-08-10 21:34:24 logout
2010-08-10 21:34:24 disconnect
2010-08-10 21:34:25 client ready
2010-08-10 21:34:35 store 1281440065421-file.zip complete
2010-08-10 21:34:35 logout
2010-08-10 21:34:35 disconnect

Note that all of these were complete within 15 seconds, and all of the resulting files on the server are corrupt.

I have also tested without setting any timeouts and the problem still occurs.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

时光匆匆的小流年 2024-09-20 20:30:10

Commons FTP 默认为 Ascii 文件类型。当处理 ZIP 文件等二进制数据时,您需要将其设置为 Binary。

来自 http://commons.apache.org/网/api/org/apache/commons/net/ftp/FTPClient.html

FTPClient 的默认设置是使用 FTP.ASCII_FILE_TYPE 、 FTP.NON_PRINT_TEXT_FORMAT 、 FTP.STREAM_TRANSFER_MODE 和 FTP.FILE_STRUCTURE 。唯一直接支持的文件类型是 FTP.ASCII_FILE_TYPE 和 FTP.BINARY_FILE_TYPE 。

您需要在发送文件之前执行 setFileType(FTP.BINARY_FILE_TYPE) 操作。

Commons FTP defaults to Ascii file types. You want to set it to Binary when dealing with binary data like a ZIP file.

From http://commons.apache.org/net/api/org/apache/commons/net/ftp/FTPClient.html

The default settings for FTPClient are for it to use FTP.ASCII_FILE_TYPE , FTP.NON_PRINT_TEXT_FORMAT , FTP.STREAM_TRANSFER_MODE , and FTP.FILE_STRUCTURE . The only file types directly supported are FTP.ASCII_FILE_TYPE and FTP.BINARY_FILE_TYPE .

You want to do setFileType(FTP.BINARY_FILE_TYPE) before you send the file.

写给空气的情书 2024-09-20 20:30:10

解决方案

我遇到了同样的问题,并通过调用

ftpClient.setFileType(FTP.BINARY_FILE_TYPE)

before every 方法解决了它 retrieveFile, retrieveFileStream, storeFile

解释

文件是已损坏,因为默认文件类型是 FTP.ASCII_FILE_TYPE。这会导致这个问题。如果您在 Linux 上,所有字节 \n\r (Windows 文件结尾)都会更改为 \n 字节。这会损坏文件。

为了避免这种行为,您必须调用ftpClient.setFileType(FTP.BINARY_FILE_TYPE)。不幸的是,每个 connect 方法都会将此设置重置回 ASCII_FILE_TYPE
就我而言,甚至可以通过 listFiles 方法重置。我猜,发生这种情况是因为我在 ftpClient 上使用 passiveMode

因此,如果您想避免麻烦,在每次文件传输之前调用setFileType(FTP.BINARY_FILE_TYPE)

Solution

I had the same issue and solved it by calling

ftpClient.setFileType(FTP.BINARY_FILE_TYPE)

before each method retrieveFile, retrieveFileStream, storeFile

Explanation

File is corrupted, because default fileType is FTP.ASCII_FILE_TYPE. This causes the issue. If you are on linux all bytes \n\r (windows end of file) are changed into \n byte. And this corrupt the file.

To avoid this behavior you have to call ftpClient.setFileType(FTP.BINARY_FILE_TYPE). Unfortunately, this setup is reset by each connect method back to ASCII_FILE_TYPE.
In my case this was reset even by method listFiles. I guess, that this happened because I use passiveMode on ftpClient.

So if you want to avoid troubles call setFileType(FTP.BINARY_FILE_TYPE) right before every file transfer.

も星光 2024-09-20 20:30:10

尽管指定了二进制文件类型,但我还是遇到了这个问题,因此我编写了代码来通过MD5哈希验证上传的文件:

public void upload(String sourceFilePath) throws Exception
{
    while (true)
    {
        // Upload
        File sourceFile = new File(sourceFilePath);
        String sourceFileHash = MD5Checksum.getMD5Checksum(sourceFilePath);
        String remoteFile = sourceFile.getName();

        try (InputStream inputStream = new FileInputStream(sourceFile))
        {
            boolean successful = ftpClient.storeFile(remoteFile, inputStream);

            if (!successful)
            {
                throw new IllegalStateException("Upload of " + sourceFilePath + " failed!");
            }
        }

        // Download
        File temporaryFile = File.createTempFile("prefix", "suffix");
        try (OutputStream outputStream = new BufferedOutputStream(new FileOutputStream(temporaryFile)))
        {
            boolean successful = ftpClient.retrieveFile(remoteFile, outputStream);

            if (!successful)
            {
                throw new IllegalStateException("Download of " + sourceFilePath + " failed!");
            }
        }

        String downloadFileHash = MD5Checksum.getMD5Checksum(temporaryFile.getAbsolutePath());
        Files.delete(temporaryFile.toPath());

        // Make sure the file hashes match
        if (sourceFileHash.equals(downloadFileHash))
        {
            break;
        }
    }
}

MD5Checksum.java

import java.io.*;
import java.security.MessageDigest;

public class MD5Checksum
{
    private static byte[] createChecksum(String filename) throws Exception
    {
        try (InputStream fileInputStream = new FileInputStream(filename))
        {
            byte[] buffer = new byte[1024];
            MessageDigest complete = MessageDigest.getInstance("MD5");
            int numRead;

            do
            {
                numRead = fileInputStream.read(buffer);
                if (numRead > 0)
                {
                    complete.update(buffer, 0, numRead);
                }
            } while (numRead != -1);

            return complete.digest();
        }
    }

    public static String getMD5Checksum(String filename) throws Exception
    {
        byte[] checksum = createChecksum(filename);
        StringBuilder result = new StringBuilder();

        for (byte singleByte : checksum)
        {
            result.append(Integer.toString((singleByte & 0xff) + 0x100, 16).substring(1));
        }

        return result.toString();
    }
}

MD5 代码取自此处

I had this problem despite specifying binary file type so I wrote code to validate the uploaded file via MD5 hashing:

public void upload(String sourceFilePath) throws Exception
{
    while (true)
    {
        // Upload
        File sourceFile = new File(sourceFilePath);
        String sourceFileHash = MD5Checksum.getMD5Checksum(sourceFilePath);
        String remoteFile = sourceFile.getName();

        try (InputStream inputStream = new FileInputStream(sourceFile))
        {
            boolean successful = ftpClient.storeFile(remoteFile, inputStream);

            if (!successful)
            {
                throw new IllegalStateException("Upload of " + sourceFilePath + " failed!");
            }
        }

        // Download
        File temporaryFile = File.createTempFile("prefix", "suffix");
        try (OutputStream outputStream = new BufferedOutputStream(new FileOutputStream(temporaryFile)))
        {
            boolean successful = ftpClient.retrieveFile(remoteFile, outputStream);

            if (!successful)
            {
                throw new IllegalStateException("Download of " + sourceFilePath + " failed!");
            }
        }

        String downloadFileHash = MD5Checksum.getMD5Checksum(temporaryFile.getAbsolutePath());
        Files.delete(temporaryFile.toPath());

        // Make sure the file hashes match
        if (sourceFileHash.equals(downloadFileHash))
        {
            break;
        }
    }
}

MD5Checksum.java:

import java.io.*;
import java.security.MessageDigest;

public class MD5Checksum
{
    private static byte[] createChecksum(String filename) throws Exception
    {
        try (InputStream fileInputStream = new FileInputStream(filename))
        {
            byte[] buffer = new byte[1024];
            MessageDigest complete = MessageDigest.getInstance("MD5");
            int numRead;

            do
            {
                numRead = fileInputStream.read(buffer);
                if (numRead > 0)
                {
                    complete.update(buffer, 0, numRead);
                }
            } while (numRead != -1);

            return complete.digest();
        }
    }

    public static String getMD5Checksum(String filename) throws Exception
    {
        byte[] checksum = createChecksum(filename);
        StringBuilder result = new StringBuilder();

        for (byte singleByte : checksum)
        {
            result.append(Integer.toString((singleByte & 0xff) + 0x100, 16).substring(1));
        }

        return result.toString();
    }
}

The MD5 code is taken from here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文