Affects Version/s: 2.0, 2.1.0, 2.3.0-RC1
Fix Version/s: None
java version "1.6.0"
Java(TM) SE Runtime Environment (build pmz3160sr3-20081108_01(SR3))
As part of the checksum verification algorithm, ChecksumHelper converts the checksum file to a String:
FileReader reads the file as a sequence of bytes, which FileUtil.readEntirely() then converts to a String using the platform's default encoding, because no other encoding is explicitly specified.
The checksum can be a local file or retrieved over the network. Currently, the encoding of the checksum file depends on the default encoding of the platform that generated it.
On z/OS, the default encoding is EBCDIC (IBM-1047). Therefore, if the checksum file was created on an ASCII system, the checksum String ends up as garbage and the checksum comparison fails.
In my environment, specifying ISO-8859-1 explicitly both when encoding and decoding the checksum String solves the problem:
I'm not sure whether this is a sufficiently generic solution - for example, it could cause backwards compatibility issues. An alternative might be to attempt to guess the encoding of the checksum file when it is read, based on the byte values.
Another workaround could be to specify the system property -Dfile.encoding=ISO-8559-1 on the command line, but this is a bit of a big hammer. In particular, it is not suitable when Ivy is used within an application where we don't to assume all input is ISO-8559-1. This is related to issue