*** If you have the problem with reading your picture card, you'll find in that thread a lot of useful hints. ***

*** Bingo! 81% of photos recovered completely; 9% are fit to some corrections in GIMP; 10% useless ***


I have a big problem. Last night I took a lot of pictures using my Fujifilm FinePix F30 camera with Olympus xD Picture Card (H 512 MB) -- among them a dozen or so of really great pictures. At home I tried to mount my picture card using hama USB 2.0 Card Reader and my newly installed Slackware 12.1 but I couldn't do it. I'm not familiar with 2.6 series kernels and all those magic devices, so I switched back to Slackware 11.0 with 2.4 series kernel and tried to mount that card as I did it in the past but without success. Then I put it back to the camera and it said: ``CARD NOT INITIALIZED''. Finally I switched to Windows XP. It suggested me to format my picture card. I don't want to format it. I'd like to recover my pictures.

My picture card was good before I removed it from my camera and something wrong happened when I attached it to my machine and tried to mount it in my new system. Now it's useless.

The xD picture card in hama's card reader should be seen in the system as /dev/sdd1 device. When I plugged in to my machine the card reader with the picture card for the first time /var/log/messages registered:

kernel: usb 4-4: new high speed USB device using ehci_hcd and address 3
kernel: usb 4-4: configuration #1 chosen from 1 choice
kernel: scsi1 : SCSI emulation for USB Mass Storage devices
kernel: scsi 1:0:0:0: Direct-Access Hama Card Reader CF 1.9C PQ: 0 ANSI: 0 CCS
kernel: sd 1:0:0:0: [sda] Attached SCSI removable disk
kernel: sd 1:0:0:0: Attached scsi generic sg0 type 0
kernel: scsi 1:0:0:1: Direct-Access Hama Card Reader MS 1.9C PQ: 0 ANSI: 0 CCS
kernel: sd 1:0:0:1: [sdb] Attached SCSI removable disk
kernel: sd 1:0:0:1: Attached scsi generic sg1 type 0
kernel: scsi 1:0:0:2: Direct-Access Hama CardReaderMMC/SD 1.9C PQ: 0 ANSI: 0 CCS
kernel: sd 1:0:0:2: [sdc] Attached SCSI removable disk
kernel: sd 1:0:0:2: Attached scsi generic sg2 type 0
kernel: scsi 1:0:0:3: Direct-Access Hama Card Reader SM 1.9C PQ: 0 ANSI: 0 CCS
kernel: sd 1:0:0:3: [sdd] Attached SCSI removable disk
kernel: sd 1:0:0:3: Attached scsi generic sg3 type 0
kernel: sd 1:0:0:3: [sdd] 1024000 512-byte hardware sectors (524 MB)
kernel: sd 1:0:0:3: [sdd] Write Protect is off
kernel: sd 1:0:0:3: [sdd] 1024000 512-byte hardware sectors (524 MB)
kernel: sd 1:0:0:3: [sdd] Write Protect is off
kernel: sdd: unknown partition table

At the same moment /var/log/syslog registered:

kernel: sd 1:0:0:3: [sdd] Assuming drive cache: write through
kernel: sd 1:0:0:3: [sdd] Assuming drive cache: write through

When I tried the command mount -t vfat /dev/sdd1 /mnt/tmp it complained:

mount: special device /dev/sdd1 does not exist

The command fdisk -l /dev/sdd displayed some information about my picture card but complained about invalid partition table:

Disk /dev/sdd: 524 MB, 524288000 bytes
17 heads, 59 sectors/track, 1020 cylinders
Units = cylinders of 1003 * 512 = 513536 bytes
Disk identifier: 0xffffffff

Disk /dev/sdd doesn't contain a valid partition table

The command fdisk /dev/sdd displayed less valuable information:

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xecb40075.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): q

I have two questions:

1. Does Linux can damage the picture card?

2. How can I recover my pictures, and if I can't, is there any service capable to do it?

At the moment the second question is much more important for me than the first.

Help me, please.

Have a nice day...

w1k0

Do you have an identical card? Maybe you could copy the first 256 bytes from a good card to the bad one and see if the file system itself is damaged.

To things to google for to recover files from a fat32 filesystem are testdisk and photorec.
http://www.cgsecurity.org/wiki/TestDisk

Yanking the card out without using a safe unmounting procedure can corrupt the filesystem. Linux often uses an asynchronous writing system, which means that the data actually sits in a buffer for a while before physically being written to disk, so you have to make sure the data is synced before removing it. Calling the umount command in cli will automatically run sync before finishing the unmount, and there's also a 'sync' command you can use to do it manually. In gui there's likewise always some kind of 'unmount' or 'safely remove' option.

You can try to run dosfsck on the drive and see if you can get it to repair the filesystem. Failing that there are some recovery tools that can find lost files, such as such as testdisk/photorec.

BTW, when it comes to data recovery it's usually a good idea to use dd or ddrescue to create an disk image to work on instead of working directly on the drive itself.

Well, I very much doubt that Linux did anything to your card unless you typed some incredibly silly commands.

I reckon that you may have better luck with:

mount -t vfat /dev/sdd /mnt/tmp

because it looks like (as in many cameras), the card does not have a real partition table or the card reader "ignores" the partition table, and everything is just stored straight onto the card itself.

If not, an idea would be to do:

dd if=/dev/sdd of=/image-of-my-card

and analyse the image file that you get from that. This will prevent any further damage occuring to your card by things that you try, because you'll have "backed up" an image of it.

You can then make multiple copies of that file and do things like:

fdisk /image-of-my-card

and let it try to "fix" any problems it sees because it will be operating on the image file.

My guess would be that either the resulting file would be mountable if you don't try to look for a particular partition, contain all-zeros or you actually have a card reader not capable of reading the card properly (which can happen with cheap readers, SD cards of > 2Gb and/or SDHC cards in an SD card reader etc.).

Try a friends card reader and NEVER let anything format it, if you are determined to recover the information. You may well be able to recover a lot of things from the card's image file itself if you have a working hardware combination.

I also tend to find that my camera gives this message when it's batteries are dead, no matter what SD card I put in. It's also possible that the camera died while writing to the card which may have corrupted it.

This only really counts if data was written to the card while he had it in Linux. The commands he ran shouldn't ever write to the card.

His express question was "Can Linux damage a card", so I mentioned a way in which data can indeed get corrupted. You're right though in that it doesn't necessarily apply to this situation.

To jschiwal:

I haven't identical picture card. I will buy it if I'll haven't recovered data from the present one using any other methods.

Thank you for the valuable link. I will consider the use of TestDisk carefully.

To David the H.:

I don't removed that card without unmounting it -- in fact I couldn't even mount it because of the corruption of the file partition table.

I tried the method you suggest:

# dd if=/dev/sdd of=xd-dd.img
dd: reading `/dev/sdd': Input/output error
63968+0 records in
63968+0 records out
32751616 bytes (33 MB) copied, 105.335 s, 311 kB/s

The command dd cannot read entire /dev/sdd. I will consider the use of dosfsck on the drive.

Thank you for the help.

To David the H. (cont.):

I tried dd_rescue /dev/sdd xd-ddr.img command. It recovered slightly more bytes than dd (32768000), then stopped for a while, and then displayed thousands of errors and short summary at the end:

dd_rescue: (info): ipos: 511999.5k, opos: 511999.5k, xferd: 511999.5k
* errs: 959999, errxfer: 479999.5k, succxfer: 32000.0k
+curr.rate: 5376kB/s, avg.rate: 1100kB/s, avg.load: 12.3%
dd_rescue: (warning): /dev/sdd (511999.5k): Input/output error!

dd_rescue: (info): ipos: 512000.0k, opos: 512000.0k, xferd: 512000.0k
* errs: 960000, errxfer: 480000.0k, succxfer: 32000.0k
+curr.rate: 12195kB/s, avg.rate: 1100kB/s, avg.load: 12.3%
dd_rescue: (info): /dev/sdd (512000.0k): EOF
Summary for /dev/sdd -> xd-ddr.img:
dd_rescue: (info): ipos: 512000.0k, opos: 512000.0k, xferd: 512000.0k
errs: 960000, errxfer: 480000.0k, succxfer: 32000.0k
+curr.rate: 5435kB/s, avg.rate: 1100kB/s, avg.load: 12.3%

It looks very bad...

Now I try to figure out how to use dosfsck with one of that files.

To ledow:

I tried to mount /dev/sdd just after /dev/sdd1:

# mount -t vfat /dev/sdd /mnt/tmp
mount: wrong fs type, bad option, bad superblock on /dev/sdd,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

That command has no sense in my system.

My xD picture card is recognized by Slackware 11.0 as /dev/sdd1 and should be recognized as /dev/sdd1 by Slackware 12.1. I have also other camera -- it uses CompactFash. Both Slackwares -- 11.0 and 12.1 -- recognize it as /dev/sda1.

I tried dd as well as ddrescue, as I wrote above. The results are very poor.

I tried fdisk trick you suggest:

# fdisk xd-dd.img
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x0f623715.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

You must set cylinders.
You can do this from the extra functions menu.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 25: Inappropriate ioctl for device.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

The output of dd and the output of fdisk differ:

# cmp xd-dd.img xd-dd.img.new
xd-dd.img xd-dd.img.new differ: byte 1, line 1

Now I wonder what can I do with that new file.

To all the guys:

I've just displayed both recovered files (from dd and from ddrescue) with Midnight Commander Viewer's Hex mode. Both those files contain merely FF's -- from the beginning to the end.

Files ,,repaired'' with fdisk have 00's between sector 00000000 and 000001F0, and FF's to the end.

It looks very bad.

The photorec utility is the one I think I would start with to recover the pictures. It will recover other filetypes, but it was written particularly for this purpose:
http://www.cgsecurity.org/wiki/PhotoRec

It won't write to the device. It recovers files to your home directory.

I have used photorec on several CF cards--nice tool.

For w1k0;
It's better not to post so much stuff when describing a problem---people can get lost.

Also, flash memory does go bad. If I did not read anything else here, the part about dd not reading the whole card is suspicious. dd does not care about filesystems or anything else--it just reads raw data.

As I said above I tried both dd and ddrescue. Both don't read the drive to the end. Both report Input/output errors. Both recovered files contain only FF's -- from the beginning to the end.

***

I tried PhotoRec for the three times in three modes:

1. Paranoid : Yes (Brute force disabled)
2. Paranoid : Yes (Brute force enabled)
3. Paranoid: No

For the three times it leaved recup_dir empty.

***

I tried my camera on the internal memory. It works.

***

Now I'm pretty sure my picture card is not logically but physically damaged. I will find some data recovery company to send my picture card to it.

***

Thank you all guys for your help. It was very instructive for me. It's a pity that all those hints failed.

***

Thank you pixellany for your advice. I will try to trim down my eloquence in the future. I'm so garrulous, because I try to depict the problem entirely, and in the result I become boring. I'm sorry.

I don't understand. If you cannot re-format the card ( in your computer or in the camera) just discard it. There's nothing to repair.

Before doing anything else, get another card and try it in the camera and the computer.

As I know storage devices can be logical damaged (they require non-invasive procedures of repairing) and physical damaged (they require invasive procedures of repairing). There are companies specialized in data recovering, for example: http://www.ontrackdatarecovery.com/. Invasive recovery procedures are about twice times as expensive as non-invasive ones. Non-invasive ones are about ten times as expensive as 512 MB xD picture card.

After all my tests I'm practically sure that my picture card is not software but hardware damaged. I intend to send it to some company similar to the one mentioned above.

I don't know if I can or cannot reformat my picture card. I didn't try it. I don't want to format it. I want to recover my pictures.

If you can't recover the pictures with tools already discussed, then by all means try a recovery service.

I don't know what "hardware repair" you have in mind for a solid-state device, but I wish you the best of luck. But first, you really should try another card to be sure you don't have some other issue.

Because I decided to send the card to the service, I thought I will try before some more invasive commands...

# dosfsck /dev/sdd
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Currently, only 1 or 2 FATs are supported, not 255.

# fdisk /dev/sdd
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x072f941d.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): x

Expert command (m for help): p

Disk /dev/sdd: 17 heads, 59 sectors, 1020 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 0 0 0 0 0 0 0 0 00
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00

Expert command (m for help): v
1023999 unallocated sectors

Expert command (m for help): q

...while dosfsck sees 255 FATs, fdisk in expert mode shows that the partition table is empty. I decided to alternate the partition table...

# fdisk /dev/sdd
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xc77998e8.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

# fdisk -l /dev/sdd

Disk /dev/sdd: 524 MB, 524288000 bytes
17 heads, 59 sectors/track, 1020 cylinders
Units = cylinders of 1003 * 512 = 513536 bytes
Disk identifier: 0x00000000

Disk /dev/sdd doesn't contain a valid partition table

...before the disk identifier was 0xffffffff now it's 0x00000000. Fdisk was unable to set it to 0xc77998e8. Apparently there are some problems with reading and writing that card...

# ls /dev/sd*
/dev/sda /dev/sdb /dev/sdc /dev/sdd

# dd if=/dev/sdd of=/root/xd.img
dd: reading `/dev/sdd': Input/output error
63968+0 records in
63968+0 records out
32751616 bytes (33 MB) copied, 105.325 s, 311 kB/s

...I tried to use /dev/sdd becase there is no /dev/sdd1 in the system...

...dd can read about 32 MB of the entire 256 MB and ends with errors. The image contains almost exclusively the pattern of FFs with a few blocks of 00s inside (to see the image's content I used Midnight Commanders's F3 (View), F4 (Hex) options)...

The picture card mentioned above is logically completely dead. The only hope is in physical methods of restoring data.

As I said in the beginning: ``My picture card was good before I removed it from my camera and something wrong happened when I attached it to my machine and tried to mount it in my new system. Now it's useless''.

Just for your in knowledge I repeated the same set of the commands with some CompactFlash digital memory card (1024 MB) to show you how should look the output of these commands with the unbroken card (that card is inserted in the sda slot of the reader)...

# dosfsck /dev/sda
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Logical sector size is zero.

# fdisk /dev/sda

The number of cylinders for this disk is set to 1986.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): x

Expert command (m for help): p

Disk /dev/sda: 16 heads, 63 sectors, 1986 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 1 1 0 15 63 961 63 2001825 06
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00

Expert command (m for help): v
62 unallocated sectors

Expert command (m for help): q

# fdisk -l /dev/sda

Disk /dev/sda: 1024 MB, 1024966656 bytes
16 heads, 63 sectors/track, 1986 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1986 1000912+ 6 FAT16

# ls /dev/sd*
/dev/sda /dev/sda1 /dev/sdb /dev/sdc /dev/sdd

# dd if=/dev/sda1 of=/root/cf.img
2001825+0 records in
2001825+0 records out
1024934400 bytes (1.0 GB) copied, 149.339 s, 6.9 MB/s

...I used /dev/sda1, because it exists and I'd like to mount the image in the file system...

# mount -o loop /root/cf.img /mnt/tmp/

...now I mounted the image of the card in the system...

# ls -R /mnt/tmp/
/mnt/tmp/:
dcim

/mnt/tmp/dcim:
196olymp

/mnt/tmp/dcim/196olymp:
p6060530.jpg

...and I can see there is one picture on that card...

# umount /mnt/tmp/

Remark: With the valid card the image of the device (for example /dev/sda) should be 32256 bytes greater than the image of the partition (for example /dev/sda1) -- the former contains some additional information at the beginning.