TotalCommander 10.00 - Checking the checksum in cache?

[retalv]

Sorry for the question and although by mistake I use the wrong section, but I have a question regarding checksum verification (any kind): I give a small example ...

O.S. Win7
Physical memory 16GB

If I copy with TC a large file with checksum, for example an ISO image, from a system drive to an external RAID5 (of which I have evidence of access or non-access to the disks) by performing the checksum verification on the disk of destination I have no evidence of access to RAID5 (the LEDs of all disks do not show any access), it would therefore seem that the verification of the ISO file just copied is done on the contents of the cache instead of on the RAID5 array.

Is there a way to force TC to "physically" re-read the file on the target disk?

I know that I can start the copy with the following verification of the data (in this case, once the writing is finished, the verification starts automatically in the background too) but I don't understand what seems to me an inconsistency of the checksum verification.

Best regard

[retalv]

For completeness...
The anomalous behavior occurs only if archive and CRC are copied to the destination simultaneously: by copying the CRC after the archive, the chache is probably "dirty" then the archive is re-read to be compared with the CRC.

[ghisler(Author)]

No, the checksum function isn't meant to verify the integrity of a disk (that's handled by the operating system), it's meant to verify that files received from elsewhere (e.g. remote backups, file transfers) are intact.

[retalv]

I understand that the purpose for which the routine has been implemented mainly concerns files imported into the system from the outside (download), but it is useful (and often recommended) to create a CRC for the important files that you intend to store locally.
Although the HDD store has a very low error rate (in 35 years this has happened to me only once, but it was enough ...), if the files are important it is good practice to save the CRC with them for future certainty that the file has not undergone any changes, not creating it after copying them to the destination disk, but to the starting disk.
Beyond the reasons why the function exists, the fact that when what has been explained happens it is not certain that in the target file a cluster has not been corrupted before it is used or during or after the copy and also of the method that I have found to get around the problem, do you think it is very complicated to implement a memory wash or to avoid any risks, or you must necessarily perform the copy with verification (with what follows in terms of machine time) on backup files of the order of 1.5TB (Macrium)?
I understand that you can live without it, but why not do it in the next version of TC?