5 ms·

> Counterfeit cards correctly report the capacity shown on the packaging, but actually contain far less. You won’t notice this until the card fills up unexpecte

by brazzy 7y ago

> Counterfeit cards correctly report the capacity shown on the packaging, but actually contain far less. You won’t notice this until the card fills up unexpectedly quickly. Oh, it's much worse than that. Counterfeit cards are often manipulated to lie to the OS about their capacity as well. They don't "fill up" at all, they just throw away your data, or overwrite it silently.

MisterTea 7y ago
That is downright evil. I suppose in order to find an evil card one would have to fill it with a file and then verify that files integrity, a very time consuming process form larger cards.
- Rychard 7y ago
  Not to mention that counterfeit cards are normally much slower, further increasing the tediousness of this process.
- rtkwe 7y ago
  Yeah that's the only guaranteed way to find them I've found. There's a couple programs out there that do exactly that. Just start writing files to the SD card and read then read them back. I think they should be a bit more intelligent though, seems like right now they write the whole value you enter as the stated/test value then try to read it back, seems like you could detect bad devices much sooner by doing smaller read tests at set intervals.
- fheld 7y ago
  the German Computer magazine heise made a tool[0] to verify the capacity by filling it up with random files: [0] https://www.heise.de/download/product/h2testw-50539 https://www.heise.de/download/product/h2testw-50539
  - gruez 7y ago
    You don't even need such a tool if you're on mac/linux or have msys/cygwin/WSL installed on windows. just do dd if=/dev/urandom bs=1048576 count=5000 | tee test.bin | md5sum (substitute bs=1048576 count=5000 with the actual size of the sd card) then do md5sum test.bin and check whether the two hashes match.
    - rlpb 7y ago
      Watch out there: the kernel will cache what it wrote out, and all you'll end up checking is the cache and not the card. dd has a "nocache" option but it's only a request. "direct" might work; I don't know. Maybe someone will come along and provide references to a a definitive answer on what the behaviour will be. My point is: it's not trivial to ensure that you're actually testing the right thing.
      - bryanlarsen 7y ago
        The trivial solution is to to do the two MD5 sums on two different machines.
        pmoriarty 7y ago
        Wouldn't removing the card, putting it back in on the same machine and then doing your second hash be sufficient?
      - deleted 7y ago
        [deleted]
      - mason55 7y ago
        You can always unmount and mount the SD card between writing and verifying. The unmount should force the kernel to truly flush everything and do the physical write.
        rlpb 7y ago
        > The unmount should force the kernel to truly flush everything and do the physical write. True, but this doesn't necessarily guarantee that the subsequent read will come from the card and not the cache. It might as currently implemented; I don't know. But without specific evidence that it does and will continue to do so indefinitely, I wouldn't assume it for verification purposes. I make the same point again: it's not trivial to ensure that you're actually testing the right thing.
- jolmg 7y ago
  Or instead of files just write to the block device with one big random file with the supposed byte-accurate size of the device, then read it back and compare. Something like: dd bs="$(blockdev --getsize64 "$device")" count=1 if=/dev/urandom of=random-file dd if=random-file of="$device" cmp random-file "$device" Using cmp instead of something like md5sum is better since it would stop on the first differing byte, instead of reading the whole thing for both. EDIT: I'm not sure if my use of dd's bs and count is a good idea, though. It might be better to do: head -c "$(blockdev --getsize64 "$device")" /dev/urandom > random-file to get more reasonable buffer sizes. Documentation on head says -c works on bytes, not characters, so that's good. For that second line, I often prefer to do: pv random-file > "$device" to get a neat progress bar. EDIT 2: As discussed in other threads, one should make sure to invalidate the kernel's cache of the device between steps 2 and 3. My safest bet on how to do that is to reboot the computer.
jamiethompson 7y ago
This is my experience. Bought an SanDisk card to pop in my phone before I went on holiday. Changed my camera settings to save to the SD card. Great. I can stop worrying about filling up my phone's internal storage with photos now. Then the card corrupted all of my photos.
- jcranberry 7y ago
  It must've been a counterfeit. SanDisk is a reputable company headquartered in US owned by a US company. I don't know consumer law (and IANAL in general) but I'd imagine if they were selling fraudulent sd cards they'd probably get hit with fines, a class action lawsuit, and possibly worse.
  - wolco 7y ago
    Happened to me. Before we blame SanDisk the problem exists in older Andriod OS.

by brazzy 7y ago

MisterTea 7y ago

That is downright evil. I suppose in order to find an evil card one would have to fill it with a file and then verify that files integrity, a very time consuming process form larger cards.

Rychard 7y ago
Not to mention that counterfeit cards are normally much slower, further increasing the tediousness of this process.
rtkwe 7y ago
Yeah that's the only guaranteed way to find them I've found. There's a couple programs out there that do exactly that. Just start writing files to the SD card and read then read them back. I think they should be a bit more intelligent though, seems like right now they write the whole value you enter as the stated/test value then try to read it back, seems like you could detect bad devices much sooner by doing smaller read tests at set intervals.
fheld 7y ago
the German Computer magazine heise made a tool[0] to verify the capacity by filling it up with random files: [0] https://www.heise.de/download/product/h2testw-50539 https://www.heise.de/download/product/h2testw-50539
- gruez 7y ago
  You don't even need such a tool if you're on mac/linux or have msys/cygwin/WSL installed on windows. just do dd if=/dev/urandom bs=1048576 count=5000 | tee test.bin | md5sum (substitute bs=1048576 count=5000 with the actual size of the sd card) then do md5sum test.bin and check whether the two hashes match.
  - rlpb 7y ago
    Watch out there: the kernel will cache what it wrote out, and all you'll end up checking is the cache and not the card. dd has a "nocache" option but it's only a request. "direct" might work; I don't know. Maybe someone will come along and provide references to a a definitive answer on what the behaviour will be. My point is: it's not trivial to ensure that you're actually testing the right thing.
    - bryanlarsen 7y ago
      The trivial solution is to to do the two MD5 sums on two different machines.
      - pmoriarty 7y ago
        Wouldn't removing the card, putting it back in on the same machine and then doing your second hash be sufficient?
    - deleted 7y ago
      [deleted]
    - mason55 7y ago
      You can always unmount and mount the SD card between writing and verifying. The unmount should force the kernel to truly flush everything and do the physical write.
      - rlpb 7y ago
        > The unmount should force the kernel to truly flush everything and do the physical write. True, but this doesn't necessarily guarantee that the subsequent read will come from the card and not the cache. It might as currently implemented; I don't know. But without specific evidence that it does and will continue to do so indefinitely, I wouldn't assume it for verification purposes. I make the same point again: it's not trivial to ensure that you're actually testing the right thing.
jolmg 7y ago
Or instead of files just write to the block device with one big random file with the supposed byte-accurate size of the device, then read it back and compare. Something like: dd bs="$(blockdev --getsize64 "$device")" count=1 if=/dev/urandom of=random-file dd if=random-file of="$device" cmp random-file "$device" Using cmp instead of something like md5sum is better since it would stop on the first differing byte, instead of reading the whole thing for both. EDIT: I'm not sure if my use of dd's bs and count is a good idea, though. It might be better to do: head -c "$(blockdev --getsize64 "$device")" /dev/urandom > random-file to get more reasonable buffer sizes. Documentation on head says -c works on bytes, not characters, so that's good. For that second line, I often prefer to do: pv random-file > "$device" to get a neat progress bar. EDIT 2: As discussed in other threads, one should make sure to invalidate the kernel's cache of the device between steps 2 and 3. My safest bet on how to do that is to reboot the computer.

jamiethompson 7y ago

This is my experience. Bought an SanDisk card to pop in my phone before I went on holiday. Changed my camera settings to save to the SD card. Great. I can stop worrying about filling up my phone's internal storage with photos now. Then the card corrupted all of my photos.

jcranberry 7y ago
It must've been a counterfeit. SanDisk is a reputable company headquartered in US owned by a US company. I don't know consumer law (and IANAL in general) but I'd imagine if they were selling fraudulent sd cards they'd probably get hit with fines, a class action lawsuit, and possibly worse.
- wolco 7y ago
  Happened to me. Before we blame SanDisk the problem exists in older Andriod OS.