Total Commander

So, assuming that FILE_FLAG_NO_BUFFERING works properly, there is no chance that files are different, but will be compared as identical during verification (to be more precise: there is such a possibility, but two errors must overlap: byte XX must be written as YY, but during verification it must be read incorrectly again as XX; there is no way to detect this case, so there is no need to discuss it).

So, in my personal opinion, verification function may be restored:
1) files are different and verified as different -> no problem,
2) files are same and verified as same -> no problem,
3) files are different and verified as same -> not possible, as I assumed here at the beginning of this note -> no problem,
4) files are same and verified as different -> well, this probably means that a reading error occured - user will be warned, that something is wrong, so verification function may be useful.

Case 4 may be also caused by write error, not only read error. And FILE_FLAG_NO_BUFFERING flag should detect it also, if Windows really rereads file from target device ignoring cache (it will require to flush cache before).

I've got one question.

Documentation for File Buffering contains additional requirements for using FILE_FLAG_NO_BUFFERING flag:
a) file accesses must be sector-aligned (sector size may be obtained by using IOCTL_STORAGE_QUERY_PROPERTY - this is recommended since Vista / Server 2008, or by using GetDiskFreeSpace),
b) memory buffer must be sector-aligned - this may be achieved by using VirtualAlloc API or by allocating (RequiredSize + SectorSize - 1) bytes and using aligned pointer to the memory buffer.

Does TC meet there requirements?

TC uses a 64k block and it's also sector-aligned in memory.

So it seems that TC does all that is possible to verify files reliably.

I appreciaty the verify option (I was always wondering why it wasn't implemented). It would, however, be even more useful if TC didn't remember the last state but reset (re-enable) the verify checkbox every time F5 is pressed.

I was wondering why verify after copy was added, but that's another story..

F1 4.b wincmd.ini wrote:VerifyCopy=1 Verify files after copying, supports all copy methods except for the Explorer method

HTH
Holger

tommy0910 wrote:I appreciaty the verify option (I was always wondering why it wasn't implemented). It would, however, be even more useful if TC didn't remember the last state but reset (re-enable) the verify checkbox every time F5 is pressed.

The state is reset to the default value or value specified in wincmd.ini each time TC is restarted.

white wrote:The state is reset to the default value or value specified in wincmd.ini each time TC is restarted.

Yes, I know that, but I would prefer it being reset each time the copy dialog is called. When temporarily disabling the verify for less important but large files (videos, etc.), I caught myself several times of not re-enabling the option.