snakyjake

Thank you: The "-h, --pre-hash" option is a great option to have!

For this scenario, the file isn't corrupted. The scenario is some sort of rare memory problem that ECC is supposed to mitigate. I'm trying to better understand why ECC is necessary, and if I can get away with non-ECC. My understanding is non-ECC could corrupt hash and parity. Not sure if SnapRAID could verify correct parity or needs to rely on ECC memory for 100% reliability.

What happens when there's a parity/integrity mismatch between the file checksum and the stored checksum? Assuming non-ECC RAM. Scenario 1 (stored bad checksum): When first checksum created, bad checksum was created because a memory anomalie. This should signal a "bad" file, and the "bad" file needs to be replaced with the "good" file. Since both files are really the same, because it was a bad checksum not a bad file, the good file overwrites the "bad" file. However, SnapRAID still thinks the file...

Why is a recovery bit option not implemented (like WinRAR)? When data is archived for long periods of time, hard drives and other media deteriorate and cause errors, it would seem adding recovery information to an archive would be valuable. Thanks.

Could there be a way to generate and compare checksum file integrity by not using ECC RAM memory?

I'd like a feature to store my encrypted rss feeds, history, configuration, into...

How do I upgrade to .NET 4.5 (linux)?

I don't want to get bad hashes caused by memory errors. Can SnapRAID do its own memory...