Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
7.4k views
in Java FTP by
I sent in a report about what I thought was a bug on FTPTransferType a few months ago. It seems to me that FTPTransferType.ASCII.equals(FTPTransferType.BINARY) because of the way the FTPTransferType class is coded. Here is the relevant code of the FTPTransferType class:

     /**
      *   Represents ASCII transfer type
      */
     public static FTPTransferType ASCII = new FTPTransferType();

     /**
      *   Represents Image (or binary) transfer type
      */
     public static FTPTransferType BINARY = new FTPTransferType();


Of course, the problem is that any call to setType() on FTPClient class will result in a binary transfer of files - regardless of whether your argument to setType() is FTPTransferType.ASCII or FTPTransferType.BINARY. In the setType() source below, notice that the line marked with the $ will always be true - thus we'll always have a binary file transfer. I fixed this in my local copy of code but didn't see in propagated to this November release. Now I'm interested in the secure code and obviously interested in having this bug fixed - if it is indeed a bug. I feel like it is because some of my transfers were being corrupted.

    /**
     *  Set the transfer type
     *
     *  @param  type  the transfer type to
     *                set the server to
     */
    public void setType(FTPTransferType type)
        throws IOException, FTPException {

        // determine the character to send
        String typeStr = FTPTransferType.ASCII_CHAR;
$       if (type.equals(FTPTransferType.BINARY))
            typeStr = FTPTransferType.BINARY_CHAR;

        // send the command
        String reply = control.sendCommand("TYPE " + typeStr);
        lastValidReply = control.validateReply(reply, "200");

        // record the type
        transferType = type;
    }


Thanks.

2 Answers

0 votes
by
Why do you think that the line below is always true?

if (type.equals(FTPTransferType.BINARY))

Surely this is not true when type is FTPTransferType.ASCII?

The equals method is not overridden, so object references are being compared. Only two instances of the class exist, FTPTransferType.ASCII and FTPTransferType.BINARY, and being different instances, their object references will be different.

So if you supply FTPTransferType.ASCII to the method, the line will be false, and typeStr will remain FTPTransferType.ASCII_CHAR.

Please correct me if you think I'm wrong. However the JUnit tests are reasonably rigorous and do check for binary and ASCII transfers - I hope they check correctly!
0 votes
by
PS I'll be very happy when JDK 1.5 is ubiquitious. Amongst other very cool features (generics, autoboxing etc) is typesafe enums.

Hurrah, finally classes like FTPTransferType (which was possibly overkill anyway), won't be necessary. If only enums were present from the beginning. I think it took pressure from C# for the Java designers to see the light.

Categories

...