Checking the File Hash

[ShadowMeow]

Using a different drive, I'm checking that the file hash remains the same before and after a level 5 scan.
Test should confirm that a level 5 scan does not corrupt user's data on a good drive.

https://pastebin.com/raw/qFt7LdHa

 

[Steve]

James: During development and testing I built a hashing function into SpinRite. Since it's doing serious work on typically large 16MB buffers, using it slows SpinRite way down. But if you give SpinRite the "hash" term on the command-line it will, when finished, dump a hash to the DOS command prompt.

What I and many others were doing was doing a Level 1 or 2 read pass over some smaller region of the drive with the "hash" parameter to get the "before" hash. Then do whatever you want with a higher level with the hash term, and then confirm that the hashes match. (I should note that as Joep (above) has said, there's really not a lot of point to that since this has already been done extensively during testing and I used it when I was deliberately inducing huge numbers of read and write errors into drives to verify that all of SpinRite's logic was always doing the right thing. We would not be at release candidate stage if it did not always pass that testing! : )

 

[ShadowMeow]

> During development and testing I built a hashing function into SpinRite.
I did not know that until you told me, so did my own hash checks. : )

> There's no reason to assume level 5 would do any harm with/to healthy sectors so it seems a bit of a waste of time.
No harm in me confirming this as part of my evaluation process either.

 

[Steve]

No harm in me confirming this as part of my evaluation process either.

None at all.

 

[ShadowMeow]

Same drive but inside a USB enclosure this time.
BIOS does not have the 137GB USB limit bug.

Final hash check after a level 5 scan over USB connection.
100GB partition placed at the end of the 1TB drive.
USBCHK used to present the drive over SCSI.

Hash Checks: PASSED