I've come across an issue with Ant's <checksum> task that has me completely perplexed. I've embedded the task in the target to build my war for the web app.
The checksum is generated and put in the file myApp.war.MD5. It is then moved to our Linux machine and is to be validated there. However, when i run it blows up with
If I generate the checksum on the Linux host and check it the same way, it works fine. But, that defeats the purpose...
Has anyone seen this before? know what the fix is?
Thanks for the response, David. I tried setting the format attribute to "md5sum" and that generated a checksum file with the format '{0} *{1}', where 0 is the checksum, and {1} is the filename. It still couldn't be verified with 'md5sum -c' from the Linux host. I even tried setting the pattern attribute to '{0} {1}', which matches the md5sum format when generated from Linux.
the resulting file sun.txt.MD5 is verified correctly using using
Have you considered the possibility that you are actually corrupting the file while transferring it? Did you remember to tell FTP to use binary mode?
Retired horse trader.
Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
James Tillington
Greenhorn
Joined: Nov 30, 2004
Posts: 7
posted
0
Thanks for the suggestion, James. I tried this and then FTP'd the file to the Linux host in binary mode. Tried it again, with the same error. I tried converting the file to Unix format using dos2unix, tried it again and got the same error.
James Tillington wrote:Thanks for the suggestion, James. I tried this and then FTP'd the file to the Linux host in binary mode. Tried it again, with the same error.
All I can say is that it works for me.
I tried converting the file to Unix format using dos2unix, tried it again and got the same error.
I don't see how this could make any difference at all. A file is a file is a file and what line endings are used does not affect the MD5 digest at all as long as the same line ending is used on both sides. The only way the digest will be different on each side is if the files do not have the same content. I still think you may be corrupting the file during the transfer. In your position I would check the file length on each side.
James Tillington
Greenhorn
Joined: Nov 30, 2004
Posts: 7
posted
0
James, I completely agree. I've tried different FTP methods, with the same results.
The new discovery is this. I generated the checksum on the Linux host (MD5SUM) and compared it to the checksum file sent from my Windows machine.
Then...
Then I converted the file to Unix format
If I remember right, when a file is transferred via FTP as ASCII, line endings should be converted to the destination OS format... still missing something.
Why on earth would you use dos2unix on a 'war' file? A 'war' file is a binary file and does not have lines so why are you changing the line endings.
Transfer the file in binary mode and do not process it any other way or you will corrupt it.
James Tillington
Greenhorn
Joined: Nov 30, 2004
Posts: 7
posted
0
James Sabre wrote:
James Tillington wrote:
Then I converted the file to Unix format
Why on earth would you use dos2unix on a 'war' file? A 'war' file is a binary file and does not have lines so why are you changing the line endings.
Transfer the file in binary mode and do not process it any other way or you will corrupt it.
I'm not converting the war file. I'm converting the MD5 file. That file is created on my Windows machine, then transferred to the Linux host. I tried transferring using both ASCII and binary modes, but each time the file ended up on the Linux host with DOS line endings. That's why I explicitly converted the file. After I ran dos2unix on the MD5 file, 'md5sum -c' worked.