Commons Net
  1. Commons Net
  2. NET-409

FTPClient truncates file (storeFile method)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 3.0.1
    • Component/s: FTP
    • Labels:
      None
    • Environment:

      Windows 7/Eclipse 3.6.2

      Description

      Functionality works fine on commons-net-2.2. Error occurred after upgrading library to commons-net-3.0 version. Sending a file from Windows 7 to CentOS/Linux using FTPClient storeFile method results in truncation of files over 2k in size. Rolling back upgrade to commons-net-2.2 version fixes problem.

        Issue Links

          Activity

          Jon Ericson created issue -
          Jon Ericson made changes -
          Field Original Value New Value
          Description Functionality works fine on commons-net-2.2. Error occurred after upgrading library to commons-net-3.3 version. Sending a file from Windows 7 to CentOS/Linux using FTPClient storeFile method results in truncation of files over 2k in size. Rolling back upgrade to commons-net-2.2 version fixes problem. Functionality works fine on commons-net-2.2. Error occurred after upgrading library to commons-net-3.0 version. Sending a file from Windows 7 to CentOS/Linux using FTPClient storeFile method results in truncation of files over 2k in size. Rolling back upgrade to commons-net-2.2 version fixes problem.
          Sebb made changes -
          Fix Version/s 3.0 [ 12314126 ]
          Hide
          Sebb added a comment -

          Works fine for me. You'll need to provide sample code that fails on 3.0 and works with 2.2.

          Please try using the example code as follows:

          java examples.ftp.FTPClientExample -s <host> <user> <password> <remotefile> <localfile>

          Show
          Sebb added a comment - Works fine for me. You'll need to provide sample code that fails on 3.0 and works with 2.2. Please try using the example code as follows: java examples.ftp.FTPClientExample -s <host> <user> <password> <remotefile> <localfile>
          Hide
          Jon Ericson added a comment -

          Per your request, the following sample class demonstrates the issue. My original description is not entirely accurate; it is not files over 2k in size that is truncated, but instead the file size "rounds down" to the nearest 1k and truncates the rest.

          The "Declaration.txt" file used in this example is the U.S. Declaration of Independence. It is 7.94KB on my local drive in Windows. On arriving at the server, it is only 7K, truncating the last few sentences.

          Truncation occurs when the commons-net-3.0.jar is used. Changing the .jar on the class path to use the commons-net-2.2.jar, the file is transmitted in its entirety.

          ###

          package com.jericson.stuff;

          import java.io.BufferedReader;
          import java.io.ByteArrayInputStream;
          import java.io.FileReader;
          import java.io.InputStream;
          import org.apache.commons.net.ftp.FTPClient;

          public class Net_409_Demo {

          /**

          • @param args
            */
            public static void main(String[] args)
            Unknown macro: { String independence = getStringFromFile(); FTPClient ftpClient = new FTPClient(); try { ftpClient.connect("b2b.myserver.com"); ftpClient.login("testuser", "Testpassword"); InputStream stream = new ByteArrayInputStream( independence.getBytes("UTF-8")); ftpClient.storeFile("Independence.txt", stream); ftpClient.quit(); ftpClient.disconnect(); } catch (Exception e) { e.printStackTrace(); }
            System.out.println("** Complete **");
            }

            private static String getStringFromFile() {

            /*
            * The file "Declaration.txt" begins with <Declaration>, ends with
            * </Declaration> and has no line separators in between.
            */
            try { BufferedReader reader = new BufferedReader(new FileReader( "Declaration.txt")); StringBuilder stringBuilder = new StringBuilder(); stringBuilder.append(reader.readLine()); return stringBuilder.toString(); } catch (Exception e) { e.printStackTrace(); } return null; }

            }

          ###

          Show
          Jon Ericson added a comment - Per your request, the following sample class demonstrates the issue. My original description is not entirely accurate; it is not files over 2k in size that is truncated, but instead the file size "rounds down" to the nearest 1k and truncates the rest. The "Declaration.txt" file used in this example is the U.S. Declaration of Independence. It is 7.94KB on my local drive in Windows. On arriving at the server, it is only 7K, truncating the last few sentences. Truncation occurs when the commons-net-3.0.jar is used. Changing the .jar on the class path to use the commons-net-2.2.jar, the file is transmitted in its entirety. ### package com.jericson.stuff; import java.io.BufferedReader; import java.io.ByteArrayInputStream; import java.io.FileReader; import java.io.InputStream; import org.apache.commons.net.ftp.FTPClient; public class Net_409_Demo { /** @param args */ public static void main(String[] args) Unknown macro: { String independence = getStringFromFile(); FTPClient ftpClient = new FTPClient(); try { ftpClient.connect("b2b.myserver.com"); ftpClient.login("testuser", "Testpassword"); InputStream stream = new ByteArrayInputStream( independence.getBytes("UTF-8")); ftpClient.storeFile("Independence.txt", stream); ftpClient.quit(); ftpClient.disconnect(); } catch (Exception e) { e.printStackTrace(); } System.out.println("** Complete **"); } private static String getStringFromFile() { /* * The file "Declaration.txt" begins with <Declaration>, ends with * </Declaration> and has no line separators in between. */ try { BufferedReader reader = new BufferedReader(new FileReader( "Declaration.txt")); StringBuilder stringBuilder = new StringBuilder(); stringBuilder.append(reader.readLine()); return stringBuilder.toString(); } catch (Exception e) { e.printStackTrace(); } return null; } } ###
          Hide
          Sebb added a comment - - edited

          That explains why my test worked and yours did not. As it happens, the file I used was a multiple of 2k bytes, so the error was not exposed.

          Code has been fixed now, and will be in the next release.

          Snapshot has been uploaded to https://repository.apache.org/content/repositories/snapshots/commons-net/commons-net/3.0.1-SNAPSHOT/

          Thanks for reporting the issue.

          Show
          Sebb added a comment - - edited That explains why my test worked and yours did not. As it happens, the file I used was a multiple of 2k bytes, so the error was not exposed. Code has been fixed now, and will be in the next release. Snapshot has been uploaded to https://repository.apache.org/content/repositories/snapshots/commons-net/commons-net/3.0.1-SNAPSHOT/ Thanks for reporting the issue.
          Sebb made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Sebb made changes -
          Fix Version/s 3.0.1 [ 12316459 ]
          Sebb made changes -
          Link This issue is duplicated by NET-411 [ NET-411 ]
          Sebb made changes -
          Link This issue is duplicated by NET-413 [ NET-413 ]
          Sebb made changes -
          Link This issue is duplicated by NET-417 [ NET-417 ]
          Sebb made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          VS added a comment -

          This problem is still valid in version 3.3.
          I copy a file of dimension 1.921.303 and at the destination the dimension is 1.921.283.
          This is the code.
          client = new FTPClient();
          client.connect(server);
          int reply = client.getReplyCode();

          if(!FTPReply.isPositiveCompletion(reply))

          { client.disconnect(); System.err.println("FTP server refused connection."); return; }

          else {
          if(client.login(userName, password)) {
          System.out.println("FTP connected");
          System.out.println("FTP logged in");
          fis = new FileInputStream(srcFileName);
          if(!client.storeFile(dstFileName, fis))

          { String raspuns_text = client.getReplyString(); client.logout(); return; }

          System.out.println("FTP file stored");
          client.logout();
          System.out.println("FTP logged out");
          } else

          { return; }

          }

          Show
          VS added a comment - This problem is still valid in version 3.3. I copy a file of dimension 1.921.303 and at the destination the dimension is 1.921.283. This is the code. client = new FTPClient(); client.connect(server); int reply = client.getReplyCode(); if(!FTPReply.isPositiveCompletion(reply)) { client.disconnect(); System.err.println("FTP server refused connection."); return; } else { if(client.login(userName, password)) { System.out.println("FTP connected"); System.out.println("FTP logged in"); fis = new FileInputStream(srcFileName); if(!client.storeFile(dstFileName, fis)) { String raspuns_text = client.getReplyString(); client.logout(); return; } System.out.println("FTP file stored"); client.logout(); System.out.println("FTP logged out"); } else { return; } }
          Hide
          Sebb added a comment -

          Is the file actually truncated, or just shorter?
          The difference is that a truncated file has some bytes missing from the end, whereas a shorter file may have bytes missing anywhere.

          One cause of missing bytes is using ASCII file transfer inappropriately.

          Show
          Sebb added a comment - Is the file actually truncated, or just shorter? The difference is that a truncated file has some bytes missing from the end, whereas a shorter file may have bytes missing anywhere. One cause of missing bytes is using ASCII file transfer inappropriately.
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          3d 42m 1 Sebb 23/May/11 20:55
          Resolved Resolved Closed Closed
          282d 39m 1 Sebb 29/Feb/12 20:34

            People

            • Assignee:
              Unassigned
              Reporter:
              Jon Ericson
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development