Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
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;


2 Answers

0 votes
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
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.