Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My wife is having troubles while syncronizing the data from the SD micro card of her LG android phone to her portable pc. It keeps remaining stuck forever at a given photo (#21).

I tried to access it on our pc (windows 7 box) and... yes, there are some issues. Namely after showing the various autoplay options which kick in (will try to disable them to gain some time..), windows detects "some problem" and offers to try to fix it. I tried this (assuming it was some sort of fsck), and it didn't change the apparent behaviour of the card.

Then I went straight ahead to the only important folder (the pictures) and tried to copy it on my drive. After copying some, a not better specified input read error happens and all the remaining jpgs are corrupted.

I have tried with Piriform's Recuva or Zero Assumption Recovery: they don't go past the first read error and silently the drive gets unmounted.

Then I went with good old dd. Didn't recall the syntax for naming the devices under windows and don't have linux installed on this box: I burned a live dvd of ubuntu (oneiric ocelot) and booted into it.

The sd card appears under /dev/sdf1. dd conv=noerror if=/dev/sdf1 of=./android.img blocks after the (by now usual) 192M. I hoped that ubuntu came with ddrescue but it is not so.

Since (time for another question on a different SE) the PPPoE with this live dvd of ubuntu appears not to be working I have downloaded the .deb package via windows, and installed it. I mention this since - if needed - I don't have the full power of apt-get available, having to d/load the packages by hand.

Anyway, now ddrescue was installed. ddrescue if=/dev/sdf1 of=./android.img gave me some hope (at least a nicely formatted output) but in the end signalled errors after 192M.

The strange thing (which gives me some hope) is that by manually copying the files windows and ubuntu give me different valid files (besides a plethora of invalid jpgs). To be clear, suppose that I have three pictures pic1.jpg, pic2.jpg, pic3.jpg. Windows copies pic1.jpg and gives me corrupted version of pic2 and pic3. ubuntu copies pic2.jpg and gives me corrupted versions of pic1 and pic3.

Finally, even if dangerous, we put the card back in the phone. The Gallery application is unusably slow and gives errors at every step, but is able to actually show some of the pictures that are not accessible via windows or ubuntu. These are pictures and not the thumbnails.

A common characteristic is that everytime windows or ubuntu detect some error, they silently unmount the drive.

To recap:

  • I have manually recovered a subset of the pictures.
  • I have an img result from ddrescue, which doesn't seem particularly well functioning (I am unable to mount it under windows).
  • The cell phone appears to be able to access at least a part of the remaining pictures.
  • As you can imagine, I have a lot of fond memories to save from that stupid micro card (as in: pictures of our newborn).
  • So, can you suggest me something to try?

I would also like to know if I did mess with the filesystem by trying to mount it ? I assumed that it was some sort of vfat, which actually appears to be. The card was already not working (stuck forever while backupping) when I tried for the first time, but maybe I could have worsened the problem.

share|improve this question
Some more data recovery software options from our Android Enthusiasts sister site:… – GAThrawn Feb 14 '12 at 16:52
@GAThrawn: thanks for the link. As you can read here: We found a workaround. PhotoRec has been really good but was unable to recover everything... – Francesco Feb 19 '12 at 16:40
Try logging into your gmail account you entered when you set up the phone. The photos may have synced there. – LawrenceC Jul 21 '13 at 2:29

You must log in to answer this question.

Browse other questions tagged .