Capacity test too slow on huge fake USB drives, takes days - alternative test required

[c0xc]

Nowadays there are huge USB drives > 1 TB in size that are so incredibly slow that a test sometimes takes days to finish. And that's even though CapacityTester does not need to fill the whole drive (like other programs do, that would really take days or even weeks). For example, someone has pointed me to a fake that's being sold as external SSD with either 4 TB or 1 TB capacity (issue #10). This particular drive appears to be slow sometimes and fast other times ("fast" as in USB 2.0), it failed within a couple of hours when I first tested it and now it's very slow:

As shown in the screenshot, it ran for 3 and a half days. That's not acceptable, especially in a modern world where the average attention span has reached that of a goldfish (scnr). Seriously, nobody wants to wait more than a day to find out if the USB flash drive s/he bought from China is fake.

When I wrote this tool more than 5 years ago, all my fake drives could be tested within hours, so I didn't see the need for more than a simple volume test (volume refers to a mounted filesystem on the partition of such a USB flash drive). Now, a new test is required...

_{Additionally, in this case, the position could not be reported (0 MB). I'll have to fix that, too.}

[c0xc]

Destructive disk test

I have begun working on an alternative called destructive disk test. Unlike the original volume test (where volume refers to a mounted filesystem), the destructive disk test works on an unmounted (USB) disk drive. You can use the volume selection dialog to unmount your flash drive to be able to start a disk test on it. As the name indicates, this disk test will destroy what's on it, so afterwards you'll have to format it again (can also be done in the GUI, see issue #11).

This feature is experimental, here's a screenshot:

Note that with this destructive disk test, the 1 TB fake drive (same as shown above) could be tested in under 3 minutes (and that includes the time it took to enter the password).
The test failed after 67 GB.
So this particular external "SSD" is probably a cheap USB 2.0 card reader with a manipulated 64 GB card.

Again, this feature is experimental. Unfortunately, I threw most of my fake drives away. But those that I still have are recognized by this test. And you don't even have to wait for hours or days!

This feature will soon be available in the Linux release (as AppImage executable file, ready to run).
I hope it will be useful for other users.

[itmagpro]

3 and a half days. That's not acceptable, especially in a modern world

:)) yeah...this have some sense, but in some case critical system daemons (kill him = kill system) may be run and support some various zombie process...running him again...and again...and you can't killing him not how..and no any way, and no one cmd, no mater tty1 by root or tty7 by sudo user in GUI, no one "kill SIGNAL", and no one "sysrq key" not help you killing child or parent some zombie process, and even reboot system in "3 and a half days" - only "reset button" on PC box is solution for stop stuck system in loop ;)

from this, conclusion, that "3 and a half days" in some case may be guilty not SSD, may be guilty bugs in code some 3rd lib or some drivers, etc

[itmagpro]

...no virus, no malware.., this will be "filezilla 3.39.0", that as zombie in background (without gui) running again and again...

I remember, then be upload huge file from FAT32 (3 part.fat32, 1 part.ext4) external 1TB USB (no SSD) HDD storage to remote SFTP server, and:

• by netstat see no data transfer;
• lamp on hdd stuck on persistent light;
• filezilla background marked as "zombie", running again and again by /lib/systemd/systemd.

[itmagpro]

other FAKE 2TB USB Testing method, now from Wish.com :)

• To Good To Bee True. FAKE 2TB USB. Testing A FAKE 2TB USB Flash Memory Stick (SCAM from Wish.com) - youtube

[c0xc]

Well, there's no software without bugs and in some cases, especially if the code base has grown too much, some bugs can lead to zombies etc. But in the case of CapacityTester, the root cause is the fake drive itself which apparently got worse in this particular case. CapacityTester's original "volume test" would try to fill the whole disk, which simply takes too long on a 1TB drive, even if it detects an error during the superficial pre-check after the 64GB mark (which was not always the case during my tests). In fact, that superficial check is almost the same algorithm as that described in the video you've mentioned. I'd just have to improve the pre-check that happens during the initialization phase (i.e., before the flash drive has been filled), it would be faster but still very slow in this case.
That's why I added the (destructive) "disk test" which should detect this 1TB fake within 3 minutes, as shown in the screenshot above. "Destructive" means that you need to re-format the flash drive afterwards, which you can also do in CapacityTester (I could make it non-destructive... but not now). But this new disk test is experimental, it needs to be tested on different computers with different fake drives.

Would you be able to try the new version of CapacityTester and run the new (destructive) disk test on a fake drive, to check if it works and how many minutes it takes to detect your fake?

I recommend using the pre-built AppImage binary (could even be used on a Linux Live system), which can be downloaded here:
https://github.com/c0xc/CapacityTester/releases/download/v0.5/Capacity_Tester-x86_64.AppImage

If it works well enough and if there's demand, I'd even consider making it available for Windows, but that's not sure yet.

[bsciretti]

I found a problem on Manjaro using the AppImage version: it asks me to umount the disk, but it doesn't recognise it after umounting it.

[c0xc]

I found a problem on Manjaro using the AppImage version: it asks me to umount the disk, but it doesn't recognise it after umounting it.

Hi @bsciretti, this bug ticket is about the new disk test method, the usb volume selection dialog is unrelated, so please open a new issue. And when you do, please add more details because otherwise I won't be able to help.

Either way, I'm currently improving the new disk test and it should be preferred over the old volume test. The volume test works on a mounted filesystem (and the selection dialog also has a u/mount button). The disk test works directly on the storage device, overwriting it, so no need for it to be mounted.

[lieblingek]

Hi,

This tool seems to be a god tool, but could you build it for ARM CPU ? I want to use it on my raspberry, and I have problems with qt5 install to raspberry ubuntu. Could you build it ?
Thanks,
Have a nice day.

[c0xc]

@lieblingek Please open a separate issue. This has nothing to do with the new test routine described in this issue.

[TipsyTheCat]

is this still an experimental feature?

[c0xc]

is this still an experimental feature?

The new test correctly reported all drives I have available and I have not heard any complaints either, so no, I don't consider it experimental anymore.

Also, I've slightly redesigned the user interface so the disk test isn't hidden in the Advanced menu anymore.