[ale] semi [OT] help recovering data from memory card

[Scott Castaline]

On 10/19/2011 03:18 PM, Ron Frazier wrote:
> Hello all,
>
> I have completed the recovery of the pictures.  Thanks very much for all
> the suggestions.  There were some interesting twists to the story.
>
> First I used the dd command below to make an image of the faulty SD
> card.  I had placed sudo in front of the command.  I don't know if that
> was a mistake, but, after dd finished with the image, the file was
> locked and owned by root.  I had to use the sudo chown command to change
> the owner and group to my name.  Other than that, there were no errors
> with dd.  I then removed my relative's memory card and copied the new 4
> GB image file from my desktop to another memory stick I had.  I moved
> the memory stick to my Windows machine and ran PhotoRec on THAT memory
> stick, which had the image file on it.  I could have run it on the Linux
> system if I'd wanted, but I'm more familiar with file operations in
> Windows.  It recovered 371 photos, which, as far as I know, was all of them.
>
> Another somewhat eerie thing happened.  There were no files showing in
> the directory of the second memory stick I was using, other than the
> image file I stored there.  PhotoRec also recovered another 30 or so
> other files, of several other types besides photos, that had been on
> that memory stick long ago and were mine and had been deleted.  I know
> they never really get deleted, but it was really strange seeing them
> come back from the dead.
>
> Just for fun, after saving the photos we wanted to keep, I went into
> Windows Explorer and selected the memory stick an formatted it, being
> sure to turn off the check box that says quick format.  I then ran
> PhotoRec again on that memory card, just to see what would happen.  In
> this case, PhotoRec was unable to recover any files, which is what I
> hoped would happen.
>
> I didn't get to try the other program that was suggested, but I
> certainly appreciate that suggestion as well.  So, thanks everyone for
> all the help.  This was an interesting learning experience, especially
> the part about my files coming back from the dead.  So, be warned, if
> you put any sensitive information on a memory stick, if you don't want
> it showing up later, you'd better truly format or wipe it.
>
> Sincerely,
>
> Ron
When you copied the image file to a new stick did you use dd or just cp? 
If you just use cp or drag & drop it just copies the image as a file to 
the device. To get it as a working image you need to dd 
if=/path2file.iso/file.iso of=/dev/sd? replacing the ? with whatever is 
assigned to the stick. It then will have all of the individual files as 
before the problem on the same filesystem type.
>
> On 10/19/2011 9:59 AM, Michael H. Warfield wrote:
>> On Wed, 2011-10-19 at 09:21 -0400, David Tomaschik wrote:
>>
>>> On Tue, Oct 18, 2011 at 9:37 PM, Michael H. Warfield<mhw at wittsend.com>   wrote:
>>>
>>>> On Tue, 2011-10-18 at 08:51 -0700, Boris Borisov wrote:
>>>>
>>>>> I'm going to follow this post carefully because I have to deal with
>>>>> the same problem :) missing partition information. Actually dmesg
>>>>> gives me message : sd 1:0:0:0: [sda] Assuming drive cache: write
>>>>> through
>>>>> sda: unknown partition table
>>>>> What I am doing now is dd if=/dev/sda of=usb8gb.img just in case. Will
>>>>> take a while with this USB.1.1 that I plugged into it :)
>>>>>
>>>> If you get a hard failure, you may want to try dd-rescue on it.  That
>>>> will work around "holes" in the data and continue to recover data.  It's
>>>> what I use for hard drives, though I don't know how well it will work on
>>>> USB flash drives.
>>>>
>>
>>> I'm not sure whether or not dd-rescue has any benefits on flash media.
>>>    I would think that blocks on flash media are either functional or
>>> dead.  (The idea on dd-rescue being that the disk might be able to
>>> read it on a retried pass.)
>>>
>>
>>> Adding the conv=noerror option to dd, however, should have no downside
>>> and has the upside that blocks AFTER the unreadable block will be
>>> read.
>>>
>> The main advantage, in this case, that I see, is that it uses a divide
>> and conquer methodology where it tries to read large blocks and, if it
>> gets an error, it divides down into smaller blocks and tries to divide
>> into large blocks of errors looking for smaller islands of working
>> blocks.  I suppose that dd with conv=noerror and a minimum block size
>> would probably work as well.  I wasn't considering the retry option
>> there although one probably shouldn't discount thermal problems.  I've
>> had some flash drives that would sometimes read and then sometimes not.
>>
>>
>