Does Linux can damage the picture card?
 

*** 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''.

Appendix
 

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.

Therefore, at least that portion has no pictures in it.

Again, if dd will not read the entire card, I know no other tricks.

Try the noerror,sync options of dd. This will cause it to just keep reading when it finds an error, and it will pad the output file to accommodate those portions of the data that it couldn't read, thus retaining filesize and presumably boundaries etc.

dd conv=noerror,sync if=/dev/sdd of=myoutfileimage bs=512

This WILL force the entire card to be read. Of course, you might just only have garbage there...

Thank you jiml8 for the valuable command.

Dd used with the above switch starts to read device without errors up to about 32 MB, then stops for a while, then starts to read large block claiming about errors, then stops for a while etc:

dd: reading `/dev/sdd': Input/output error
63968+960030 records in
1023998+0 records out
524286976 bytes (524 MB) copied, 480.618 s, 1.1 MB/s
dd: reading `/dev/sdd': Input/output error
63968+960031 records in
1023999+0 records out
524287488 bytes (524 MB) copied, 480.618 s, 1.1 MB/s
63968+960032 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 480.644 s, 1.1 MB/s

From the entire 512 MB it read about 512 MB of data in comparison to about 32 MB of output of dd used without any switches.

Final myoutfileimage contains first and foremost null data (the patterns of FFs). From time to time there are small parties of data. For example the first such party starts at offset 0x00030201 and ends at offset 0x00034002, the second starts at offset 0x003381ce and ends at offset 0x0033bfff etc. Before them and between them are the patterns of FFs.

No I go to buy some new xD picture card to test my camera and my card reader, and to compare valid card to invalid one.

I compared some garbage from the above image to a few valid dscf*.jpg pictures (photos taken with Fujifilm FinePix F30).

The picture should start something like that:

ÿØÿà..JFIF..........ÿá'.Exif..II*........... ...............¨................

or something like that:

ÿØÿá'¾Exif..II*........... ...............¨.......................¸........

The first party of garbage starts from:

ÿØÿá%~Exif..II*........... ...............¨.......................¸........

(So it starts at the beginning of some picture but it is too short to include complete photo).

The second party of garbage starts from:

mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
mmmmmmmmmmmmmmmmmmmùG.¥.L"Üä.yÇaCÕ.Ô©v.?ÿ

(So it starts in random place and it is too short to include complete photo).

Etc.

YOu might also try it without the sync option. This will remove the output padding and the resulting filesize will be different than the input card size.

You might get more useful information this way, and at a minimum you will know directly how much of the card is considered to be bad.

It would be very interesting if the bad section turns out to be a power of two in size; that would suggest a bad address line in the card (which might be repairable).

I'm back here. I bought a new xD picture card. There is no in the market 512 MB cards so I was forced to buy 1 GB card.

Smaller cards are better than bigger ones. If small card fails you lose fewer pictures. The recovery of data from smaller cards is cheaper. So it's better to buy four small cards then one big one. Of course I don't take into the consideration the price, but remember: the price of the recovery of data by professional company is a few times higher than the price of the picture card.

Well... My camera works. Mu card reader works. My new card works. So now I need to send my old card to some experts...

***

Thank you jiml8 for the next advice.

# dd conv=noerror if=/dev/sdd of=/rootmyoutfileimagewithoutsync bs=512

dd: reading `/dev/sdd': Input/output error
127968+0 records in
127968+0 records out
65519616 bytes (66 MB) copied, 467.523 s, 140 kB/s
127968+0 records in
127968+0 records out
65519616 bytes (66 MB) copied, 467.571 s, 140 kB/s

# ls -l
-rw-r--r-- 1 root root 524288000 2008-06-07 16:00 myoutfileimage
-rw-r--r-- 1 root root 65519616 2008-06-07 19:07 myoutfileimagewithoutsync

524288000 - 65519616 = 458768384

It isn't a power of two (at least an integer power):

2 ^ 28 = 268435456
2 ^ 28.773190730622518 = 458768384
2 ^ 29 = 536870912

The content of myoutfileimage and myoutfileimagewithoutsync are similar: parties of garbage divided by patterns of FFs.

***

Wow!

***

And now real miracle...

I decided to try the command suggested by jiml8 at the beginning once again...

# dd conv=noerror,sync if=/dev/sdd of=mytwinoutfileimage bs=512
1024000+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 142.581 s, 3.7 MB/s

It ended work without errors!

# cmp myoutfileimage rmytwinoutfileimage
myoutfileimage mytwinoutfileimage differ: byte 27137, line 1

An here's the content of mytwinoutfileimage, which in fact isn't the twin of myoutfileimage:

1. FFs from offset 0x00000000.
2. Nice looking data starting a partition é..FF-DSC01.. .......ø}.?...5...K.....)...............FAT16 .. etc. from offset 0x00006a00.
3. Then various logically looking data.
4. 00s from offset 0x0000ac2c.
5. Then FFs, then 00s.
6. Logically looking data from offset 0x00016600.
7. 00s.
8. Nice looking set of data including phrase .5......100_FUJI ..d..
9. 00s.
10. Nice looking data such as .5......DSCF2254JPG .dÆ.Â8Â8..Æ.Â8..¬J..DSCF2255JPG ..Ñ.Â8Â8..Ñ.Â8b.....DSCF2256JPG.
11. 00s.
12. The first picture ÿØÿá%~Exif..II*....... at offset 0x00030000.
13. The consecutive pictures at offsets 0x001a8000, 0x0031c000, 0x00488000, 0x005ec000, 0x00754000, etc.

It's real miracle! I used the same command but the result isn't the same: myoutfileimage was full of FFs with small parties of garbage -- mytwinoutfileimage looks like the image of the device.

I do almost nothing between myoutfileimage and mytwinoutfileimage. In fact I do something. I used card reader with my new xD card. I can't find any other explanation of that miracle.

***

# 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: 0xffffffff

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

Yes, of course, I know.

So I try that nice command for the third time...

# dd conv=noerror,sync if=/dev/sdd of=mytripletsoutfileimage bs=512

dd: reading `/dev/sdd': Input/output error
63968+960031 records in
1023999+0 records out
524287488 bytes (524 MB) copied, 471.287 s, 1.1 MB/s
63968+960032 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 471.31 s, 1.1 MB/s

Well... The miracle can happen only once...

I can't to explain it. I simply can't.

# cmp myoutfileimage mytripletsoutfileimage
myoutfileimage mytripletsoutfileimage differ: byte 197122, line 1

How many times I run that command so many times it makes different image. Strange...

***

Now I will try to manage with pretty mytwinoutfileimage.

***

jiml8 you're a genius!

***

To be continued...

bad connection of the card to the device.

You plugged it in one time and it worked, but it is erratic. You might try cleaning the contacts, or you might just accept that you did get a good dump and go with that, and scrap out that card.

I removed 27136 bytes of data from the beginning of mytwinoutfileimage, mounted the remain in the file system, and copied 91 photos to hard disk. Bingo!

Not all photos are pretty. 1 displays nothing (that file starts with a block of FFs); 3 have at the edge narrow stripe cut up from the same photo (it's possible to frame them); 7 have more or less wide gray stripe and sometimes additional geometrical distortions (it's impossible to frame them in a reasonable way); 6 have geometrical distortions (they look like cut up into rectangles and stripes, and puzzled together in a strange way); 74 are pretty.

In total: 81% of pretty photos, 3% usable after framing, 6.5% usable if you like strange effects, 8.5% unusable. Good result assuming a few hour ago I had nothing.

I don't think that problem is caused by dirty contacts. My old picture card is clean and my old card reader reads my new card without problems. I think it's a kind of undeterministic bug in my old card. I will try to create a few mytoutfileimages to see the results.

The facts: my old picture card has invalid partition table; in most of cases my card reader can't read entirely my old picture card without errors; if it read it some photos are invalid.

Thank you very much for your assistance, jiml8.

Well... After a few attempts (between 5 and 10) dd made the second usable image of that drive -- it's a twin brother of mytwinoutfileimage.

Good news: that six pictures with geometrical distortions can be edited and corrected in GIMP. I think it will take between one and two hours of work.

So 9% can be corrected in GIMP. It means 90% are recovered. Very good result.

I am totally impressed how you stuck with this. Do you realize the percentage that give up at the first roadblock?

So we can all sleep better, please assure us that you won't try to use that card in your camera again. Flash memory simply goes bad after a while, and no amount of tweaking or formatting will change that.

I took that night the pictures of a few persons. I felt obliged to do everything I could to recover that photos -- not for me but for them.

That particular picture card is logically almost dead. I don't intend to use it for any other purpose than some tests.

Thank you all guys for your assistance. Every your tip, every your hint was valuable. Thank you very much.

Sometimes persistence pays. I have had to do things like this sometimes to recover stuff off of a dead hard drive. I once found one that would work if I stood it on edge, but not if I laid it flat.

Whatever works. Glad this worked out for you.

I just called Ontrack Data Recovery department in my country. The standard procedure takes a few days. Expert analysis costs 40 USD; recovering of the data costs from 180 to 550 USD.

The picture card can be damaged logically or physically.

As I said above there is no 512 MB xD picture cards on the market. The price of 1 GB xD picture card is 27 USD.

Your card is damaged physically. The symptoms make that absolutely clear, and if the damage was logical then dd would have extracted everything for you.

The above general remark about picture cards I referred to pixellany, who wrote in #13:

He was doubt the picture card can be physically damaged. I asked the guys from Ontrack and they said it can.

***

As for my picture card I thought so far it's logically damaged, because I could read data using software methods. Now I think you're right, jiml8. It explains strange, non-logical behavior of that card.

I read this thread now.

I would try also gnu ddrescue, that should ignore errors and will keep reading.

ex:
ddrescue /dev/sdd ~/ddrescueimage.img log.txt

And also, if you still have the xd, have you tried to put your card in the freezer before trying to make an image of it? Sometimes works with hard disks...

Also foremost is sometimes useful to recover data from images created with dd or ddrescue.

Thank you mtb for an interesting hint. I put that invalid picture card in a freezer for one hour and then I tried to read the image of it with dd. It produced small, 32 MB in size file full of FFs with some tiny fragments of the data. Freezing was pointless in that case but it doesn't mean it will be pointless in any other case.

Then I tried dd_rescue for two times. In reverse mode it produced the file of 524288000 bytes (512 MB) with short logfile reporting none errors. In forward mode it produced the file of 32768000 bytes (32 MB) with huge logfile reporting a lot of errors. Both these image files consisted from the large patterns of FFs separated from time to time with small chunks of some data.

Finally I tried GNU ddrescue in the default mode. It produced the file of 32751616 bytes (32 MB) and reported two errors in the logfile. The image made by GNU ddrescue was similar to the images produced by dd and dd_rescue: a lot of FFs and some data from time to time.

Sorry if nothing good happened, but better to try than not to try.

Trying to work with photorec and foremost on the right image could also lead to nothing, but even 1 more photo could be interesting...

All the hints are valuable. Thanks to them I tried stubbornly to gain the image of that device and I finally succeeded. I recovered 84% of the pictures. Different tips described in that thread can be useful for other guys in the future. The trick with vertically positioned hard drive is interesting as well as the trick with deep-frozen hard drive.

Ubuntu and FinePix S9600
 

Fuji FinePix S9600 filesystem problem
I have scanned the thread- and my problem is similar if a little different.

I use Hardy and the Fuji camera. It has a 2G xD card which shows up on desktop as 565.3 MB Media with a usb symbol in its icon. Over the last 18 months I have copied about 5000 images from here , by opening that folder and select and dragging them to named folders on Desktop.

Last Sunday, I repeated the process. It started and after downloading 471 of 608 it stopped and reported an 200 I/O error. I tried the process on a Windoze machine and it stopped at the same point. I didn't panic- I know that on Linux this is a challenge not a problem. I unplugged the camera and saw one of the missing photos- in fact I can see all of the photos on the camera, and even take more.

So it looks if the camera is blissfully working using its own OS, but the VFAT directory corrupts on image 472. So it looks if the first few byte of the card are blown- I must have been working them too hard.

I have fiddled around with dd fsck testdisk with zero success. I have bought a Mikomi 56-1 reader in case that helps but I really need a working xD so I can check that it is working. Though a reboot suggests it can be seen. The new 1 Gig cards are working fine so now is the time to try again.

I need some heavy duty hints on how to find the drive. How to use the tools to recover the remaining images or the last 125 or so. And like the card my memory function isn't a reliable as it was when I first used a Unix terminal 20 years ago. So don't omit the basics.

Hi all, this is grumpy guy.I have an Olympus Stylus 770 SW which of course uses the notorious xD-Picture card - M-XD1GM. (Why I just lately unpacked the camera, uw case, etc. is another tale) In hindsight the card reader problem may be more important that the UW photo qualities. The camera is useless to me if I can't upload the photos to a Linux computer and use the Gimp for further work.
I run Fedora 9 on three computers in the Philippines. I have been Microsoft free for 10 years and I have no intention of subjecting myself to the power/control policies of the windows folks.
I keep reading all these horror stories about card reader/card problems. Can any one point me in the direction of a multi-card reader that works with this card AND Linux.. Even sarcastic responses may have value. Thank you much, Grumpyguy
<jarlynne@maui.net>

I suppose every card reader should work. I use cheap hama's USB 2.0 Card Reader 35 in 1. It works perfectly. The problem discussed above concerned spoiled picture card and had nothing to do with the card reader.

xD = "MTD", not block device
 

I realize it has been ages since the previous post in this thread. Still I like to add some info.

Other than (u)SD, CF and SM cards, xD cards do not have an internal IDE-adapter. The adapter is necessary to translate between "flashy" memory (MTD, memory technology device) and block device memory.

xD cards omit the adapter which could lower the cost of the card. The adapter has to be implemented either in hardware or in software. Some cameras have hardware for that, some leave it to the host: the (MS Windows) driver that came with the camera.

Linux comes with MTD-drivers. Not important for this thread but maybe handy to know is that the implementation was not optimal, resulting in slower access to the MTD.

Important for this story though, is that for quite a while cheaper "all-in-one" card readers would not (fully/reliably) support xD, because the necessary hardware would be missing.

A lot of info can be found at http://www.linux-mtd.infradead.org/faq/general.html and on wikipedia under MTD and FTL (flash translation layer)

Sorry for not deeplinking to the appropriate information, it has been a while since I first took that info to me and the details are a bit vague.

Thank you for increasing our -- or at least mine -- knowledge about flash devices and MTD. As I see you registered here in 2007 and you post one message each year. I think it's high time to increase your reputation in LinuxQuestions.org.