1

I have a couple hundred of "fake" flash drives; The kind you would see on online store, with false/questioning sizes, like "1TB" or "1ZB"...

How do i know they are "fake"? They basically stop the transfer of files after some point, where they basically fail and the OS where the transfer happen usually show an error.

Now i did manage to check for the real size of such flash drive, and set them to their real size, a while ago (couple years ago, so i don't remember the exact procedure), but i did so:

  • Fill flash drive until error come up, and note down/print the actual/exact size of said data when the error comes up (since it would indicate the real size of said flash drive).
  • "format" the flash drive to it's real size, by using dd.

I'm already partially aware on how to do the first part. The problem comes at the second part, which I'm not entirely sure how it is done, though i do remember that back then, when i did it, i used dd to write an empty image file i created, of the exact, real size of the flash drive, and used dd with it.

Some might think/argue that, "it is useless" or "the effort outweigh the result", which might be true if i only had one or two of these, but given that i always can find a use for these flash drives, even if not practical (due to the amount), it doesn't mean it's useless.

It is also possible given i managed to do it once, though i forgot about it...(and others probably managed to do something similar, though i didn't find any such examples on linux)

I don't have any data on these, and i also do not care if they break (given the amount i have) but i would still prefer setting them to their real size, as previously stated.

I basically want to do all of this with bash, dd, and some other Posix utilities.

2
  • 2
    Maybe you used fdisk? Because dd to change the partition table is not going to be easy... Nov 5 '20 at 2:25
  • I think yeah. But as mentioned, the memory of that time is fuzzy, beside what i mentioned in my post...wish i took notes :/ @AlexisWilke Nov 5 '20 at 15:54
4

You can use the tool f3 for this. It is a linux-port of H2testw (german).

F3 is included in most major Distributions like debian, ubuntu and fedora

EDIT: you cannot fix the size of the stick/card/whatever without changing the firmware which is not a trivial task. But f3 provides the command f3fix which creates a partition with the real size of the stick so you cannot “overcommit” data by accident.

2
  1. Use dd (badblocks in read-write mode with a test pattern could be a much better option) to wipe them and write down the real size.
  2. Use fdisk/gdisk/sfdisk/cfdisk/whatever to create a single partition of the right use. Most of them can be trivially automated - probably the easiest one would be sfdisk /dev/device < partition_table_file.
10
  • 2
    I’d be cautious about using dd to find out the real size. Many of these fakes will successfully write to the end of their reported size. They do it by mapping the same physical area to multiple addresses. So dd would just keep writing. You often have to read back in some way. Nov 5 '20 at 7:01
  • I noticed that too on some of mine. Some doesn't show any error even when exceeding the actual real size, and then, if i plug/replug or mount/remount the said drive, it would show non-existent file or some of the file i transferred would be deleted. @PhilipCouling Nov 5 '20 at 13:24
  • mind giving an example so i can test it? Just that providing example/code to do it would help better :) Nov 5 '20 at 13:26
  • @PhilipCouling badblocks then? ;-) Nov 5 '20 at 14:43
  • @ArtemS.Tashkinov I doubt it. The trouble is each individual block will write and immediately read back. It's just that some will overwrite each other. I suspect badblocks will not write everything and then read everything. Nov 5 '20 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.