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.