I have a SanDisk 128 GB Micro SD that used to be in my android phone. I first noticed (on the phone) that photo albums that were located on the SD opened correctly sometimes and sometimes not at all. So I took the card out to backup the files to my pc. When I mount it, I can list and see all the files, I can even copy some files sometimes, but mostly it results in the copying process just freezing and eventually giving the error:

Error splicing file: Input/output error

There's specifically one wav-file I am trying to copy that constantly fails, the weird thing is that I managed to play it halfway through once, then while trying to jump forward it froze. So it seems that some files are ok and others not, but it seems almost arbitrary at times.

What I've tried:

  • I have tried mounting it on two different computers in two different card readers, both in Windows and in Ubuntu, copying using both standard drag/drop, cp and teracopy, resulting in the same behaviour.
  • I have run checkdisk in windows with fix errors turned on, but it just ended after a while without any output whatsoever, and the problem persisted.
  • I would like to try and run 'check/fix filesystem' from the disk utility in ubuntu 18.04, but that option is not avaible (grey). I have tried unmounting the card in Disks and still I cannot run the check/fix utility.

I have installed testdisk and photorec but have yet to try them out, as they seem to be more for recovering deleted files, and I am not sure how to (or if I even need to) use them for my purpose. Also, may I set Photorec to recover all files, and not just specific file types?

Question: Do anyone have any idea of what's going on and/or how I would best go about fixing the error? To be clear, I do not care about continuing to use the card, only recovering as much data as possible.

TL;DR: I can list all files on my Micro SD, and even read parts of some files, but copying larger amounts of data fails with input/output error.

fdisk -l for disk 'sdm':

Disk /dev/sdm: 119,1 GiB, 127865454592 bytes, 249737216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdm1       32768 249737215 249704448 119,1G  7 HPFS/NTFS/exFAT

Be careful, that card is dying and you can make it worse.

If you absolutely need these files, contact a data recovery company and let them do their job. It will be expensive.

If you can take the risk, make a ddrescue image of the card and work on the read-only image rather than the card itself. ddrescue is designed to pull easily accessible data first, then try harder with problematic (and riskier) sectors. If it gets stuck, heating up or chilling the card may help. Sometimes it's the temperature that works, sometimes the process of changing temperature.

Once you have the image, try to mount it and copy your files off of it. You shouldn't get read errors at this point since you're reading from a functional device now, but some files may be corrupted where data couldn't be read.

There shouldn't be a need for file carving tools like photorec since the filesystem appears to be functional. testdisk is unnecessary too, your partitions are fine.

Tools like chkdsk won't help since it's not a damaged filesystem alone that is a problem, but the hardware. Trying to fix it only stresses the card further. It could make sense to run chkdsk if recovering from an image runs into filesystem errors, but you should do it on a clone rather than original card.

  • Ok, I have ddrescue working on it now. I only had another 128GB disk to image to however, and not that much space left on any drive at the moment. But if say the MSD is only filled with ca. 90GB, would I be fine with imaging to a 128GB, or would I still need to be imaging to a bigger device than the source? (And great answer may I add, thank you.) – Christopher.L Oct 1 '20 at 12:23
  • Also, the files are not important enough to pay a recovery company, I'll take my chances with rescue software. – Christopher.L Oct 1 '20 at 12:48
  • If ddrescue uses sparse files, then 128 GB should suffice... assuming enough data is unreadable to account for filesystem overhead on the target. Otherwise you'll fill up the disk and ddrescue will stop, although it should let you continue later on a larger drive. I'm not sure if it's using sparse files though, in that case it will stop before the first round (easy parts) is done. – gronostaj Oct 1 '20 at 14:02

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.