Quaraxkad

I've taken this opportunity to upgrade the server hardware. Rebuilding the parity on the old hardware would have just been way too slow. It's now got a much faster CPU and ECC RAM. There is a strong possibility that the inconsistency(s) you've already posted are a consequence (side-effect) of a prior (underlying) issue. I have had errors in the past, which I always suspected was due to non-ecc memory. My logs go back to 2021-01-01. "Internal inconsistency in state for block x state y" first occured...

Yes, I get the error on every command, diff, sync, even status. I did try loading from the second content file and had the same error. I just went back through the logs to find the first occurence. It happened at the end of a successful sync, after the wait time graph, but before it saves and verifies the content files (which it didn't do), and a slightly different error message: Internal inconsistency in file sequence for file 'redacted.filename' at '0:13021' and at '13022:3686' Internal inconsistency...

I've got this error message that tells me to report the issue on the forums, so here it is! Loading state from c:/program files/snapraid/snapraid.main.content... Internal inconsistency for parity overlap for files 'redacted.filename' at '5917601:16708' and '<deleted>' at '5930622:1' Internal inconsistency in file-system for disk 'a6' after read Stacktrace of snapraid v12.2, mingw, gcc 4.9.4, 64-bit, PATH_MAX=1024 [bt] 00: 000000000043710e [bt] 01: 0000000000419c98 [bt] 02: 000000000041a807 [bt] 03:...

I occasionally need to restore accidentally deleted files, and since they were deleted from a network share they are not in the Recycle Bin, so I'll run: snapraid fix -m --filter "missing filename.ext" With my large 47-disk array (incl. 4 parity), this takes a very long time to restore even a 1KB file. The fix itself occurs very quickly, it's the time before it begins the restoration that's the issue. It runs through "Searching disk n", "Filtering", "Scanning disk n", etc, and then after the "Fixing"/"Checking"...

I occasionally need to restore accidentally deleted files, and since they were deleted from a network share they are not in the Recycle Bin, so I'll run: snapraid fix -m --filter "missing filename.ext" With my large 47-disk array (incl. 4 parity), this takes a very long time to restore even a 1KB file. The fix itself occurs very quickly, it's the time before it begins the restoration that's the issue. It runs through "Searching disk n", "Filtering", "Scanning disk n", etc, after the "Fixing"/"Checking"...

When a file is discovered as unrecoverable, it would be very helpful if the logfile would print out a friendly list of the other files that the unrecoverable file was hashed against. The standard output doesn't tell you at all when a missing/changed file contributes to a fix failure, and the verbose output is so enourmous it's difficult to parse. There are already "msg:expected: Missing file" entires in the -l log, but they are mixed among so many other log entires it's difficult to tell which unrecoverable...

When a file is discovered as unrecoverable, it would be very helpful if the logfile would print out a friendly list of the other files that the unrecoverable file was hashed against. The standard output doesn't tell you at all when a missing/changed file contributes to a fix failure, and the verbose output is so enourmous it's difficult to parse. There are already "msg:expected: Missing file" entires in the -l log, but they are mixed among so many other log entires it's difficult to tell which unrecoverable...

Every line starting with : is a GOTO label, you can't have duplicates in the same script. It looks like you are using them as comments, which should be prefixed with REM or :: and not :. It's not ideal, but the quickest and easiest way to make this script work as it is (and without having to learn any new batch and command line syntax!), change all the : labels in the second half, just add the number 2 to the end of them (no spaces, so :RunDiff becomes :RunDiff2). Then change the GOTO calls in the...