Everything (all checksum and storage methods) can be calculated and saved in one go, but not checked, because in practice, RapidCRC Unicode seems to prefer CRC32 in the filename over CRC32 in the NTFS stream (for example) - if both are used and there is a missmatch between them -, but that's not reported to the user. Now it has somehow become intransparent which checksums RapidCRC-Unicode recognizes and are actually checked against. I don't know, if a list with the checked checksumtypes like "Filename-CRC32, Checksumfile-SHA1, NTFS-BLAKE3" in a new table-column would make it more transparent or if it will introduce much complexity without a real benifit.
The problem only occurs when several checksums are used at the same time.: I think it only affects a few power-users and the benefit might not justify the effort. I use RapidCRC Unicode intensively myself, but it is not a real problem for me.
Everything (all checksum and storage methods) can be calculated and saved in one go, but not checked, because in practice, RapidCRC Unicode seems to prefer CRC32 in the filename over CRC32 in the NTFS stream (for example) - if both are used and there is a missmatch between them -, but that's not reported to the user. Now it has somehow become intransparent which checksums RapidCRC-Unicode recognizes and are actually checked against. I don't know, if a list with the checked checksumtypes like "Filename-CRC32, Checksumfile-SHA1, NTFS-BLAKE3" in a new table-column would make it more transparent or if it will introduce much complexity without a real benifit.
The problem only occurs when several checksums are used at the same time.: I think it only affects a few power-users and the benefit might not justify the effort. I use RapidCRC Unicode intensively myself, but it is not a real problem for me.