Can a fake drive also fool TeraCopy's verify function?

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

rd369151

Member
Jan 11, 2025
16
0
This may relate to that MRU/FIFO/circular buffer thread elsewhere on here, but I want to pose it as fresh question.

If we use TeraCopy's file verification function, where it computes the checksum of the original file, and then checks is against the copied file, to see if they match, that will catch actual file errors in copying. But when it goes on to the next file, that doesn't mean that the previously copied file is still present. So a devious fake drive could have any number of files copied to it, that would verify at the moment, but wouldn't be there if a second round of comparisons was done for all the files, after the fact.

Or is this just speculation that doesn't happen in real life, with actual fake products?
 
Yes true, the current file is stored, till the circular internal flash rolls over again to overwrite the data. So the only way is to write a file, then check all files via a read, to ensure they are still there.
 
I brought up the FIFO thing as a way to allow the drive to avoid being detected as fake. I think with the actual fake products, they just fake the space after the real space, mostly by saying the write was successful, but just returns 0 on read because there's no actual storage there (or the read fails)
 
I believe the answer to the OP is the proverbial "It Depends!" There are two kinds/types of fakes out there that behave differently.

Fake #1: When the writing reaches the end of the legitimate space, subsequent writes to non existent space beyond the legitimate space generate write errors. The hacked firmware suppresses these errors and reports "All is well" to the host. No previously written files are over-written. Therefore, file comparisons will not detect this. Trying to read subsequently written files will always fail however.

Fake #2: When writing reaches the end of the legitimate space, the hacked firmware "wraps around" to the beginning of the legitimate space and begins to overwrite previously written files, either fully or partially replacing them, thus losing or corrupting data, while reporting "All is well" to the host. File comparisons WILL detect this.
 
Ah, poor choice of wording on my part. File comparison of files in the legitimate space would find nothing wrong as nothing is overwritten.

File comparison of subsequently written files would fail as the subsequently written files can never be read back.