NTFS Stream will not be checked if "checksum in filename"

[Thunderbolt32]

If the detection of "Checksum in Filename" recognises something, as in the case of _20220806_ in the filename (the date of an image in the format of a CRC32), the NTFS stream with the BLAKE3 checksum is no longer checked. That's unexpected when CRC32 calculation is disabled and only BLAKE3-checksum-calculation is enabled.

[OV2]

If a checksum is found in the filename it currently always skips looking into the stream. I could look in both locations.
The question is which one to take for determining the status. Display as verified if any one of them is calculated and matches?

In your case you can remove the underscore as hash delimiter in settings.

[Thunderbolt32]

In your case you can remove the underscore as hash delimiter in settings.

I have already done that. ^^

Checksums are used for integrity checks. Therefore, I think the status "OK" should only apply if all checksums which are found are valid at the same time, otherwise the integrity is violated and there should at least be a warning that there were partial problems.
In explicitly this case, however, the calculation of CRC32 checksums was disabled and it should therefore ignore CRC32s and only check the enabled checksum types. Maybe RapidCRC can comment in it's info message, that it found additional checksums which are not checked. ;)

[Thunderbolt32]

I need to use a better language:

An example:
We have a file with FILENAME-CRC32, NTFS-CRC32, NTFS-BLAKE3. If only BLAKE3 is enabled, RapidCRC Unicode would only calculate BLAKE3-Checksums.
So this ticket is about that RapidCRC ignores the NTFS-BLAKE3 if it founds an FILENAME-CRC32 and that it should be exactly the other way around, when CRC32 is disabled: Since it only calculates only BLAKE3, it should only care about BLAKE3. ;)

If it is a matter of dealing with Checksumfile-CRC32, FILENAME-CRC32, NTFS-CRC32 (three locations for CRC32) and maybe additional NTFS-SHA1, NTFS-BLAKE3 and so on. Currently there is a hidden rule, which one of them is checked (you mentioned it). Whether we check all of them or not, it's currently unclear which of them are recognized (That's the point of #180). You could make the decision to check all checksums, but i think the next feature request would be then to merge multiple checksum-files before checking them all at once. I think you get the idea, that RapidCRC would get a lot of database-related-feature-requests. This is the big advantage over other programs like chk.exe but also the critical point to what extent you want to expand this. ^^
This is why #180 is no priority for me and it is entirely at your discretion.