Suggestions for F5 copy dialog?

MarcinW · Post by *MarcinW » 2013-12-23, 16:31 UTC

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.

MVV · Post by *MVV » 2013-12-23, 18:18 UTC

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).

MarcinW · Post by *MarcinW » 2013-12-24, 01:06 UTC

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?

Post by *ghisler(Author) » 2013-12-24, 13:51 UTC

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

MarcinW · Post by *MarcinW » 2013-12-30, 10:22 UTC

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

tommy0910 · Post by *tommy0910 » 2014-02-23, 11:28 UTC

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.

HolgerK · Post by *HolgerK » 2014-02-23, 13:47 UTC

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

Post by *white » 2014-02-23, 13:56 UTC

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.

tommy0910 · Post by *tommy0910 » 2014-02-23, 15:58 UTC

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.