validrive says the drive is great, but its actually not.

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Announcing “BootAble” – GRC's New Boot-Testing Freeware
    Please see the BootAble page at GRC for the whole story.
  • 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.)


z80

New member
Oct 8, 2023
1
0
i have a no name 64gb drive that shows up in validrive as actually full spec. however when i go to write too it, it really dosnt want to write. go to delete, fails. when i check the drive via windows properties, it says 10gb is used, but when i look at the properties of the files on it, 360mb. i suspect something else heinous is going on. id love to send the drive or get walked through finding out myself where the issue lies. seems like an issue validrive, a drive validator, should have caught.
 
I would assume the controller on this one is failed, or the flash is EOL as well.

However I can see one issue is some drives with fake firmware that allocates a chunk for partition and FAT, then the rest is simply used to round robin keep the latest files written, overwriting older stuff, while keeping the FAT entries for it there and looking valid, but reads will come back for the current modulo x data. A way to solve this would be to randomly (about every 512M I would say) keep a hash of a page, and every time you go over the 1G mark read all of those previous LBA units again, and compare the hash, and if valid, then store the hash of the next LBA again and continue. Then after completion read all that table again, and this will then give a good confidence the drive actually stores data. Hash mismatch on a read you immediately fail the drive, unless it had a read error. Read error you fail it with read error, if there was mismatches then fail, saying the drive appears to discard data that is older, and show a table of the LBA units, the expected hash, and the current hash. I very much doubt that the drive fakers will put in firmware that will look for this behaviour, it is easier to just ignore, as they figure that nobody will return them before the taillight warranty is over.
 
  • Like
Reactions: z80
Try testing the drive with one of the other tools that exist. (Even SpinRite 6.1 if you have one of the pre-release versions working.) There is the h2testw program that does a deeper test than ValiDrive does (testing the entire contents, not a statistical sample.) https://h2testw.org/ (Please be VERY CAREFUL on that site because the ads there look like real download buttons and may lead to unfortunate results.) This site as a list of many tools, but I have never tested any, so am vetting none: https://www.geckoandfly.com/22803/detect-fake-usb-flash-drives-sd-cards-ssd-disk/
 
Last edited:
If you can not read to the drive or delete files, then yes, ValiDrive should somehow see this. It reads, writes 'noise', reads back (or not) noise, it writes back original data. It should notice if it can't write: Either due to the drive reporting an error or by simply not reading back what it just wrote to the drive. I suppose theoretically a large cache may feed ValiDrive the data it wrote, however ValiDrive tries to mitigate that.

Now either ValiDrive made some mistake or it can actually read and write and thus something else is going on.

when i check the drive via windows properties, it says 10gb is used, but when i look at the properties of the files on it, 360mb
Screenshots would help. BTW there can be a difference, quite a substantial difference between file sizes added up and space used in the file system due to for example large cluster sizes. Assume a 32KB size cluster, then even a 1 byte sized file occupies entire cluster. A 32KB+1b file occupies two clusters. The larger the cluster size the more these files partially occupying a cluster will add up to this wasted space.

however when i go to write too it, it really dosnt want to write. go to delete, fails
Fails how exactly?
 
i have a no name 64gb drive that shows up in validrive as actually full spec. however when i go to write too it, it really dosnt want to write. go to delete, fails. when i check the drive via windows properties, it says 10gb is used, but when i look at the properties of the files on it, 360mb. i suspect something else heinous is going on. id love to send the drive or get walked through finding out myself where the issue lies. seems like an issue validrive, a drive validator, should have caught.
I understand your point -- but that's expressly NOT what ValiDrive is for. You could certainly argue with the name, suggesting what something that calls itself "ValiDrive" should do... but then, the phrase "a drive validator" is also subject to wide interpretation. So, for the record, we KNOW what ValiDrive is for, right? Even if it not what you want it to be for in this puzzling instance. It is ONLY intended to check for the presence of declared storage across a drive's media. And, as its documentation clearly says, it's only performing a spot-check.

We DO have something that can check the entire drive... it's called SpinRite! <g>
 
I had a similar problem as the original post, i have a 128GB sandisk micro sd card, I tested it with H2testw and it shows that the drive is in fact only 7.4GB. But when i tested it with validrive it came back as ok.
I wanted to try validrive since with bigger drives it takes a long time to use other software.
From what i can see in the logs of the drive I tested, it seems that information is only discarded once the real drive is full. So on my drive i can store about 7GB of date, but once i go over that it will be lost.

I've added screenshots of the too tests also.

Thank you for the work you do with these programs it very much appreciated.
 

Attachments

  • H2testw.png
    H2testw.png
    20 KB · Views: 80
  • validrive 1.png
    validrive 1.png
    77.1 KB · Views: 76
From what i can see in the logs of the drive I tested, it seems that information is only discarded once the real drive is full.

Yes, it seems that way. If if it was type 2 hack or 'wraparound', H2TEST should show more overwritten sectors. IOW, if I am not mistaken this should have been caught by ValiDrive which detects type 1 hacks which F3 (yet another tool to detect fake flash drives) refers to as 'limbo' hacks. This appears to be a type 1 or limbo type hack indeed. If I had to guess the flash drive returned cached data to ValiDrive so it appeared as if the noise written was read back.
 
I had a similar problem as the original post, i have a 128GB sandisk micro sd card, I tested it with H2testw and it shows that the drive is in fact only 7.4GB. But when i tested it with validrive it came back as ok. I wanted to try validrive since with bigger drives it takes a long time to use other software.
Hey Pierre: As far as we know, SanDisk is a company we can and should trust. I strongly doubt that they would have any involvement in any kind of subterfuge. So, assuming that your SanDisk MicroSD is really from SanDisk and not a high level forgery (which we've never seen before) I would bet that the card is 100% authentic, that ValiDrive is correctly doing what it was designed to do, and that what you have is a defective card with errors which H2testw is misinterpreting.

(And nice job on the ValiDrive "dialog stretch" image! (y) )

If I come back to this for a ValiDrive v2, I would change the program's logic to read all 576 locations first. Write them all with unique signature patterns, read back and verify all of the signature patterns, then restore all of the original data. This would do several things: It would make ValiDrive immune to falsely passing a drive that was aliasing any of the tested sectors (though as far as I know, doing that is an urban myth that has persisted because it certainly is possible, though we have never encountered any evidence of it.) And be performing all reading and writing "all at once", I suspect that ValiDrive could run far faster on many drives where it is very slow today.

But even so, what people really want is a "SpinRite for USB under Windows." -- they want a test of USB mass storage to assure them that a drive is not only the size it claims to be, but also a reliable place to save their data. ValiDrive was intended and designed to only perform the "drive size" assurance task. :)
 
I have 2 fake drives that get all green in ValiDrive.


1) Sansumg 2 TB SD card. H2testw shows it's really 8 GB.

1698433066369.png


1698433157354.png


1698433180673.png


2) Delaihe 980 EVO 4 TB SATA SSD. I haven't run h2testw on it yet. To scan it with ValiDrive, I attached it to an M.2 to full-size SATA adapter, then a SATA to USB adapter.

1698433221428.png


1698433245320.png
 
we have never encountered any evidence of it.
@Steve:

You seem convinced that there are no drives with FIFO type behaviours despite the fact that several people have pointed out they have such drives. Perhaps you should offer to acquire one of these drives to put your doubts to rest. In the mean time, I think you should make a clear note in the ValiDrive FAQ (or in the program itself) that it is not doing an exhaustive test (and potentially recommend a program that does do such a test) and so ValiDrive can be fooled by drives like these. The last thing we want is people being convinced their drive is good by ValiDrive, only to then find out the hard way that much of their content is now gone because they wrote a lot of content and the drive only retained a little of it.
 
I would happy to acquire any of these drives to see for myself. If @ColbyBouma can/will provide link(s) for their purchase I'll be glad to follow in his footsteps, as I have previously, to grab some to characterize their behavior. (y)
 
It turns out ValiDrive can detect the fake area of my Sansumg SD card. I had encountered a bug in ValiDrive without realizing it.

This bug seems to happen when I stop a test, quickly close ValiDrive, then run another test. More detailed steps are available in the ticket.


@z80 Please reboot your computer and try running ValiDrive again.
 
UPDATE: Two “impossibly inexpensive” NVMe drives from AliExpress have arrived (1TB and 4TB) and they are indeed quite suspicious. I've opened an exploration tracking issue in GRC's GitLab for ValiDrive to contain my findings. The various SD cards which were also ordered have not yet appeared.

(Note that I do not plan to duplicate my findings here. I'll be doing that over in GRC's GitLab.)