Suppose there are two files
MyFile.ext
MyFile.md5
Focusing on MyFile.md5 and running cm_CRCcheck validates MyFile.ext.
That's good.
However, when cm_CRCcheck completes, the focus is AUTOMATICALLY SHIFTED to MyFile.ext.
That's bad.
Automatically changing the focus FOR THE USER, no matter the reason, is bad.
Please, leave it up TO THE USER to select files!!
(I hit 'DEL' thinking that the focus was on MyFile.md5 and deleted MyFile.ext instead -- argh!)
THIS IS A RELIGIOUS USER INTERFACE ISSUE: Thou shalt not muck around with the focus behind the user's back!!!!!!
The reason is complex, so I've included it as ...
... Optional Reading:
Usually, if MyFile.md5 is bad, you want to delete MyFile.ext and try downloading it again, but NOT IN THIS CASE.
MyFile.ext was on a drive connected to my laptop via USB DriveWire - I will assume the reader knows what USB DriveWire is.
MyFile.ext was KNOWN TO BE GOOD.
I was trying to copy it to the new drive inside my laptop.
The problem I was having was that normal copy/compare kept coming up with errors.
In addition to a new hard drive, I had upgraded to XP SP3.
I didn't know whether my copy/compare problem was caused by noise on the USB, by the USB DriveWire, or by a bad SP3 driver.
I created MyFile.md5 on both the source (USB) and destination drives to help me figure it out.
Usually, this is what you want to do:
D:\MyFile.ext-->USB-->cm_Copy-->C:\MyFile.ext
D:\MyFile.ext-->USB-->cm_CompareFilesByContent<--C:\MyFile.ext
Repeat the above until success.
(Good luck!)
Result: COMPARE ERROR... COMPARE ERROR... COMPARE ERROR...
(over and over and over).
So I tried doing this instead:
D:\MyFile.ext-->USB-->cm_CRCcreate-->USB-->D:\MyFile.md5
D:\MyFile.ext-->USB-->cm_CRCcheck<--USB<--D:\MyFile.md5
PART A: Repeat the above until success; then:
D:\MyFile.ext-->USB-->cm_Copy-->C:\MyFile.ext
C:\MyFile.ext-->cm_CRCcreate-->C:\MyFile.md5
D:\MyFile.md5-->USB-->cm_CompareFilesByContent<--C:\MyFile.md5
PART B: Repeat the above until success.
The above may look like silliness but it's not.
1: MyFile.ext is 800 MBytes - fewer reads==less time lost.
2: MyFile.md5 is 76 bytes.
3: The chances of getting a USB error on a 76 byte transfer (to perform the check) is almost zero.
4: True, creating D:\MyFile.md5 does involve reading from the USB (with possible errors), but it does not involve simultaneously trying to read two 800 MB files (as would be the case doing a head-to-head comparison of the two .ext files).
D:\MyFile.md5 was bad because of problems with the USB, not because D:\MyFile.ext was bad.
I was trying to repeat cm_CRCcreate on the USB until I got a good cm_CRCcheck on the USB in preparation for PART B.
Understand?
What happened: cm_CRCcheck changed the focus from D:\MyFile.md5 to D:\MyFile.ext without me knowing it so when I hit the 'DEL' key my KNOWN TO BE GOOD file disappeared!!!!
It's gone.
It was my only KNOWN TO BE GOOD copy.
I'm very unhappy.
cm_CRCcheck unexpected behavior - data loss
Moderators: Hacker, petermad, Stefan2, white
- MarkFilipak
- Member
- Posts: 164
- Joined: 2008-09-28, 01:00 UTC
- Location: Mansfield, Ohio
- ghisler(Author)
- Site Admin
- Posts: 50475
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
The cursor is placed on the last file which has an invalid checksum - all such files are selected. This behaviour is by design.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com