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

Thu Oct 20 09:23:51 EDT 2011

On Thu, 2011-10-20 at 02:44 -0400, Ron Frazier wrote:
> On 10/19/2011 10:10 PM, Tim Watts wrote:
> > On Wed, 2011-10-19 at 21:32 -0400, Ron Frazier wrote:

<BIG-SNIP/>

> >> Scott, I just dragged and dropped the file onto the new memory stick.  I
> >> think the FAT table was probably scrambled on my relative's original
> >> card, so I don't know if I could do the procedure you describe.  Also,
> >> the size of the memory stick and the size of the original image file
> >> were different.  In the end, the recovery program reclaimed the photos
> >> from the image file.  It just happened to also reclaim some from my
> >> memory stick that I had deleted long ago.
> >>
> >>      
> > Whoa. Something's not right in River City. Maybe Windows has some smarts
> > to recognize that it dealing with a disk image, but I would hope that it
> > would ask first whether you want to install it as a filesystem or just
> > copy it as a file.  What if you had value data on the target and were
> > just wanting to copy the file? "Bye bye Valuable Data. Thank You
> > Windows!" (Unless it sees that the target has no filesystem -- or at
> > least no filesystem that Windows cares about).
> >
> >
> >    
> 
> Hi Tim,
> 
> I'm not exactly sure what you're saying.  Let me clarify what I did a bit.
> 
> I started with a 4 GB memory card from my relative, after her Verizon 
> phone refused to read it.  All attempts to read it in Windows with 
> normal tools failed, as did an attempt to read it normally in Linux, put 
> in reader, insert into USB port, auto mounts, shows up on desktop, 
> except it wouldn't show up.  I did a dd on it, in Linux, to extract a 4 
> GB image of the card and put it in a file on the Linux desktop.  Her 
> original memory card either had a FAT or FAT32 file system, I'm not sure 
> which.  I then removed her card from the Linux computer by using the 
> disk utility to power it down first.  While still on the Linux computer, 
> I inserted a different 8 GB memory stick already formatted as FAT32.  I 
> dragged the image file from my Linux desktop to the 8 GB memory stick, 
> then ejected the memory stick.  So, I have a 4 GB image file from my 
> relative's original memory card now stored on an 8 GB memory stick, just 
> as a normal file.  I then put the memory stick into my Windows machine, 
> and ran PhotoRec on it.  I told it the file system on the target device 
> to recover was "other" which means not Linux.  It then proceeded to 
> recover her photos by reading every block on the 8 GB device, as well as 
> some old files I had deleted from MY memory stick long ago.
> 
> So, we went from faulty 4 GB memory card with FAT or FAT32 file system, 
> to 4 GB image file of said card on Linux machine, to 4 GB image file on 
> 8 GB memory stick with FAT32 file system, to recovery program running 
> under Windows accessing the 8 GB memory stick, to recovered files stored 
> on Windows system hard drive.  If it still sounds like something is 
> amiss, please let me know.
> 
> Sincerely,
> 
> Ron
> 

I see. My bad. I assumed PhotoRec would use the file system structures
on the device to navigate.  Since it seemed to work for you I started to
wonder, where did the file system come from? And then the thought
occurred to me that perhaps Windows saw that the file contained a FAT
file system and automatically installed it as such on the mem stick --
which could, of course, be disastrous if that's not what you intended.
But it does sound like the kind of "helpful" thing Windows is known for.
In retrospect, I guess it was silly thinking on my part.

So perhaps the data blocks in the file aligned just enough that PhotoRec
was able to treat it as part of the actual file system?  Maybe it uses a
file system where it can and just "bush whacks" it the rest of the way.
That could explain why it was able to recover some of your deleted files
as well.

Anyway, glad you were able to help your relative.

> >>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> 
> 
> -- 
> 
> (PS - If you email me and don't get a quick response, you might want to
> call on the phone.  I get about 300 emails per day from alternate energy
> mailing lists and such.  I don't always see new messages very quickly.)
> 
> Ron Frazier
> 
> 770-205-9422 (O)   Leave a message.
> linuxdude AT c3energy.com
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo