I've been creating a large zip file on my Windows 10 machine every couple of weeks and then copying it to a Samba network share on my QNAP device. For the past nine months, I've been using the Get-FileHash command to check the hash values of the original and the copied file to ensure there weren't any data transfer errors. However, this month, I noticed that the hashes don't match anymore. I double-checked the Windows and network share settings, but nothing seemed off. Eventually, I tried using CertUtil for the hash calculation and the hashes matched up. Has anyone else experienced differences in hash values from Get-FileHash all of a sudden? Here's a peek at how I'm using these commands: Get-FileHash "" and CertUtil -hashfile "" SHA256.
7 Answers
Your process seems to have a flaw—when you copy from Host H to share S, if you then calculate a hash on Host H using that file, you’re not confirming it’s the same as the one on the share. You could be hashing a copied byte stream rather than the original file, especially if there are issues during transfer.
By default, CertUtil generates SHA-1 hashes while Get-FileHash gives you SHA256 hashes. Make sure you specify the algorithm for both commands: for Get-FileHash, use -Algorithm SHA256 and for CertUtil, just specify SHA256 in the command. Another thing to keep in mind is that CertUtil outputs hashes in lowercase, and Get-FileHash in uppercase, which could affect your comparisons. It's tricky without knowing your exact setup, but these factors could be messing with your results.
I've never encountered any issues with this either. Can you produce a test file that shows different results? It sounds like it might be a case of the file getting modified while transferring, potentially due to the transfer mode (ASCII vs. binary?).
Maybe your Samba settings are causing some caching issues? Windows has a feature called "available offline," and if that's enabled, it might mean one command is using a cached version of the file while the other isn't. It's worth checking out, especially if you've experienced network issues lately.
There's definitely a reason for those different hash results. Switching tools isn't a long-term solution; something must have changed on your network share or in your script that caused this issue. I suggest running both Get-FileHash commands for the initial and replicated files manually to see if they produce consistent results. Also, consider whether the account running your scripts still has access to the share. Something likely altered your process, not the Get-FileHash itself.
Yeah, I get that! The commands run from PowerShell history when comparing hashes should give consistent results if everything else checks out.
Consider doing a binary difference check to see if the files are actually different. Sometimes there can be subtle issues, like Windows adding metadata or tags to files that can throw off hash comparisons.
It’s crucial to specify your hash types when comparing hashes. If you don’t, how can you be sure they’re both SHA-256? Being explicit about the algorithm ensures you’re comparing apples to apples.
Thanks for the tip! I’ve run multiple tests to ensure a stable connection during replication.