I would really like to use this plugin but I have no idea if it still works. Is it maintained still? Where is the repo. Where is the "how to use it" guide?...

1 hour ago, Bob-omb said:

I would really like to use this plugin but I have no idea if it still works. Is it maintained still? Where is the repo. Where is the "how to use it" guide?...

I don't think it ever worked. The post right above yours reports an issue that's been in it as long as I remember, and there are several reports of the same thing throughout this old thread. And that issue renders it useless. If it can't even do what it is supposed to do then there's no point to it.

Edited July 7, 20251 yr by _Shorty

The build and export seem to go ok but the export check gives an instantaneous all clear (see screenshot). 0 files checked. Is this normal or am I missing something?

23 hours ago, KingLB said:

The build and export seem to go ok but the export check gives an instantaneous all clear (see screenshot). 0 files checked. Is this normal or am I missing something?

Incase anyone is having the same issue, it looks like changing the hashing method works. I've changed it from the default method to BLAKE3 and now files are beeing checked as expected.

Out of interest, does anybody have advice on using this alongside immich? I get alerts for the .immich files which I believe are updated every time I add a file, which generate a lot of noise in the output.

Ive observes something that should certainly be brought up. Im currently putting some finishing touches on something similar to this, but with more data points and also OS agnostic.
While working on the export feature, i noticed that a lot of files, which were processed by the plugins have their extended attributs not set, they all had their user.$HASH set, but the others like filedate, scandate were absent. So its basically useless for those files as there is no info about the mdate(as the export doesnt save it). It does like an issue with spacing in the filepath/name (not even special characters, but its too many files affected that i can say for sure)

So you should absolutely check whatever files you have summed with it if theyre actually still good.

Edit:

I did a retest, because of a youtube video i saw. It seems to work at least now the biggest issue is, even the current version failed to update the files. I do gonna add a screenshot of what i discovered and this just a tiny tiny tiny bit

Edit 2
This is what the getfattr should have returned

Edited January 22Jan 22 by Mainfrezzer

Hi,

My control page always shows an orange circle = "represents and open operation".

The help text says that "For each disk the build and export state is maintained in near real-time."

To test this I added a test file (text, created with nano) to a disk and waited for 18 hours for it to appear in the export hash file. But it didnt.

It took a manual export for the file to be listed.

What is the expected behaviour?

What do the orange circles really mean?

Could it be that I am wrongly configured?

Thanks for sharing your wisdom!

Tazman

So have we decided this is worth running? I uninstalled it because everyone said it was broken and didn't help at all. And might even cause degradation from the constant scans, why run it if you have a parity drive anyway? Guess I'll reinstall it unless someone can give a good reason why not to run it.

@paradoxum parity doesn't protect against file corruption. But swapping the array drives to BTRFS would also detect bit flips, so that's an alternative to this plugin.

14 minutes ago, spyder said:

@paradoxum parity doesn't protect against file corruption. But swapping the array drives to BTRFS would also detect bit flips, so that's an alternative to this plugin.

You are correct that Parity doesn't protect against file corruption, but it does allow (when working corectly), overall detection and recovery from data corruption.

I still use this plug-in to (theoretically) identify which file(s) were involved in an unRAID parity detected data corruption.

But, so far, the only files it has reported as corrupted were not actually corrupted!

All "corrupted" files were verified as actually okay, because I happened to have another copy of the files to directly "binary compare" against.

So, I'm not actually sure why I still use this plug-in? Maybe in the hope that the author will one day fix the bugs.

But, they seem to have abandoned the project (presumably as they couldn't fix the bugs to make it actually work!).

The progress bar does not appear correctly.

It's not 98.6% complete.

There's a lot more than 8 hours 40 minutes left.

Uploading Attachment...

Thank you.

Quick question about Custom folder exclusions — are these only applied to real-time protection, or should they also apply to the scheduled Verify pass?

I've got a few paths in Custom folders (backup log dirs + an Immich library path) that are correctly skipped by the watcher, but my scheduled Verify keeps flagging them every run with "hash key mismatch (updated)" since they're log/state files that update daily as part of normal operation. Checked integrity-check.sh and the generated bunker -Vqj -n -L /mnt/diskN lines don't seem to have any exclusion args, so it looks like Verify just isn't picking up what's in Custom folders.

Re-saved Settings (toggled the day and back to force a rebuild) and the script came out the same, so wanted to check if this is expected behavior before assuming it's a bug.

Running plugin v2.5.2. Happy to share my config snippet if useful.