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.
-
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.)
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.
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.
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:
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.
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
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!
)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.
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.
1) Sansumg 2 TB SD card. H2testw shows it's really 8 GB.
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.
@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.
The Sansumg is no longer available, but the Delaihe is:
Make sure to change the selection. Most listings default to a cheap adapter, not an actual drive.
I'm willing to ship either drive to you. You have my email address
I was able to find more Sansumg cards from different sellers:
This is the dead listing I bought mine from:
This is the dead listing I bought mine from:
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.
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.)
(Note that I do not plan to duplicate my findings here. I'll be doing that over in GRC's GitLab.)
EDIT: You will only be able to open that link if you already have account in dev.grc.com, which requires a special procedure that cannot be shared here.
Last edited:
I posted it under the assumption that some people with GitLab access hang out here as well. I will update my post to clarify that.
Similar threads
- Contains 1 staff post(s)
- Contains 3 staff post(s)
