I saw your comment above that the problem seems to be in the transferring of the file. In addition to that, I just wanted to confirm what syphilis suggested: After transfer you should be using the "b" mode. From the Digest::SHA docs (emphasis mine):

The "p" mode is handy since it ensures that the digest value of $filename will be the same when computed on different operating systems. It accomplishes this by internally translating all newlines in text files to UNIX format before calculating the digest. Binary files are read in raw mode with no translation whatsoever.

The name "portable" is a bit confusing here.

I'm dumbfounded by the "feature" of a mode argument to the Digest::SHA::addfile() method. Why does a module whose simple purpose is to compute the message digest of a block of data permit monkeying with that block of data? It violates the principle of separation of concerns. Look at the trouble it caused rmahin.

There's no such feature in Digest::MD5.

Hi this is my first post.
Hello Monks!

Given that some OSes treat binary and text files differently (the latter messing around with line endings as you said in your first post), I think you really need a $mode argument to the Digest::SHA::addfile($filename [, $mode]) method.
Otherwise you'd have to do something like this to generate the hash of a file in binary mode:


open the file
set binmode
while (not EOF)
{
    read N-bytes of the file into a buffer   # don't want to read the 
+whole file into memory if it's a big file
    Digest::SHA::add($buffer)
}
close file
[download]

It's easier to just call Digest::SHA::addfile($filename "b")
It might cause fewer problems if Digest::SHA::addfile() defaulted to binary mode.