Spildit wrote:
If your cloning tool is using the same method as a OS API rather then issuing direct I/O to the drive then results might be like when scanning with windows API and PIO.
Unfortunately the Cloning tool does not use direct access to the hard drive.
Instead it goes "over" the BIOS and uses extended INT13 calls.
It runs under pure DOS.
I cannot imagine the BIOS or old DOS "repairing" bad sectors or "faking" them as good.
But I may be wrong, of course.
Maybe the "fake good sectors" come from the controller (Dawicontrol)?
But why the difference to before you repaired the translator?
Is it possible that the controller distinguishes "different types" of bad sectors?
Or is it maybe the "talking" between the controller and the firmware with the repaired translator?
Spildit wrote:
TRUE response from the drive is aquired from PIO. Maybe OS is trying to compensate for the errors and sending to victoria data that is not exactly the same data that the drive is outputing to the OS.
Your OS (windows) is not shoing to victoria the sectors that have it's ID not found and are uncorrected. If the same happens with your cloning tool using some sort of OS API then the same might happen. Tool sends request to the OS instead to use direct I/O to the drive.
Ok this sounds compelling to me, because I ran victoria from an Windows Live Environment (PE).
And I don't have much trust in windows for its treatment of hard drives
Spildit wrote:
You don't need vendor specific commands to read sectors with bad checksum. READ LONG for instance is a standard ATA command. Doing several normal standard reads to attempt a good read unsing normal standard ATA commands is an option as well.
This sounds very interesting, because this opens the possibility to improve the cloning abilities of my tool
Thank you very much for your specialist input.
This helps me understand the things better and maybe improving my cloning solution in the future if i find the time for.