[Gllug] recovering files from USB flash drive

[Peter Grandi]

>>> On Thu, 08 Sep 2005 11:23:38 +0000, "J F"
>>> <jnns at linuxmail.org> said:

jnns> Some days later, I tried to access these files and for
jnns> some strange reason, the ASCII text files turned into a
jnns> bunch of ÿ's, opening them with hexdump gives me a load of
jnns> FF's.

inns> [ ... ] Does GPG or Tar have a recovery feature?

'tar' sort of, GPG in most cases obviously cannot.

jnns> I made a 'dd' image of the drive and I'm hoping that the
jnns> missing (if it is missing) part of the file is somewhere
jnns> inside it.

Assuming that the problem was some physical IO errors, a 'dd'
copy without special options will not have been a good idea,
beause blocks in error will have been skipped. If you did not do
the 'dd' with 'conv=noerror,sync', do it again. Then burn the
resulting file to a CD-R to make sure you have a non-modifiable
backup. Perhaps something like:

  dd if=/dev/uba bs=512 conv=noerror,sync of=/var/tmp/flash.img
  cdrecord -dev /dev/hdc -fs 2000k -sao /var/tmp/flash.img

or equivalent depending on your setup.

jnns> How should I go about finding it? I think it's a FAT32
jnns> partition. How can I identify a chunk of data as being
jnns> part of this missing file?

There are lots and lots of FAT16/FAT32 recovery tools, mostly
under MS Windows. They will use various heuristics to locate
files, which often succeed, thanks to how how FAT16/FAT32 files
are represented.

After getting a proper 'sync'ed image from 'dd' like above you
might want to copy it back to a known-good flash and then invoke
on it such utilities (usually called ''undelete'' for the milder
variant, and ''unformat'' form the rougher ones).

Such utilities have different approaches which result in
recovering different stuff, and usually modify the filesystem;
so it might be a good idea to try one, get whatever it found,
copy the _original_ backup image to the flash, try the next, and
so on.

jnns> It seems GPG compresses the file, but does it do so before
jnns> or after encrypting it?

Before encryption, in part to squeeze out redundancy, in part
because proper encryption results in incompressibility.

jnns> The file contained some JPEGs, that used to be in a
jnns> windows partition. If I can't recover the file from the
jnns> flash drive, I'm thinking of looking for deleted jpegs in
jnns> my windows partition. Do JPEGs start and end with any
jnns> special magic codes?

Yes they do, and there are several utilities (again mostly under
MS Windows) to recover fragments of JPEG images and reassemble
them, especially from flash cards (your problem seems to be
rather common).


I suspect that the common reasons are that:

* Some types of flash media have really few rewrite cycles.

* FAT16/FAT32 is really not the best filesystem for flash, as it
  does have rewrite hot spots.

* People mount FAT16/FAT32 media 'rw' or without 'noatime' even
  if they are just looking at things. It is usually better to
  mount the medium 'ro', copy things off it, remount 'rw' and
  then delete stuff that needs deleting BTW.

* Most flash media do not have built in bad-sector sparing
  logic, for example the SM that my old camera uses.

A couple of the SM chits that I got have developed bad sectors
our of rewrite fatigue... I have reformated them with:

  mkdosfs -F 16 -h 63 -n Photos1 -c /dev/uba

which because of '-c' does a 'badblocks' test. I am not sure
that all or any cameras do look at the bad sector list in
FAT16/FAT32, but so far it seems to be OK, at least here.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug