I damaged my 4GB zip drive while it was plugged in. This caused the file-system to become corrupt. I cannot load it into either Ubuntu or Windows. I need a way to get my data off of it. I can connect it to the computer, but the file-system is not recognized. I have used dd to copy the contents of my device file to an external file, however about 21MB into it, it says:

dd: reading `/dev/sdb': Input/output error
43232+0 records in
43232+0 records out
22134784 bytes (22 MB) copied, 10.4637 s, 2.1 MB/s

It happens the exact same for several tries. I have read the file with a hex editor and I can find the contents of my files, however I still need the rest of the drive. It is OK if I only get the raw hex data from the drive, I can sift through it later, but I need to get the data off of it. How can I get the data off of it? Thanks.

Sometimes, depending on what's causing the error,
using dd with the option:

will allow dd get past the error. Have you tried that?

1 members found this post helpful.

It just posts those lines several times before saying this and quiting:

dd: `/dev/sdb': cannot seek: Invalid argument

It also stops at the same byte every time, except the first time I tried, when it copied almost 250MB.

OK, if there is a seek error then you might try the option:

You use it to specify a number of blocks to skip on the input. For example, in your case, it could be interesting to try a value such as 50000, or other somewhat higher values to see if you can start trying to read data after the spot where you had trouble, around block 43232. You might want to try to that combined with the

option.

If all else fails, you might be able to write a little fault tolerant program to try to specifically seek each block on the device, then if the seek is successful, read the block.

You may also be looking for a program like dd_rescue.

I haven't tested (and needed) it yet, but according to http://linuxwiki.de/dd#Defekte_Platte_sichern (in German) and the project website it doesn't just skip defect sections like dd would do with noerror option set (i.e. dd creates a file with missing bytes, the final image is smaller than the original). If you just want to get the raw data this difference may be negligible, though.

The skip works (ish), I could read my 4GB drive 10MB at a time, however I would like to do it faster. I tried dd_reasue, it doesn't work at all. However it lead to an enlightening error:

dd_rescue: (info) expect to copy 3915776kB from /dev/sdb
...
dd_rescue: (info): read /dev/sdb (10.0k): EOF

So I think that it is stopping because it fopen (which is what dd_rescue uses) says that it is at the end of the file. It may be because it is trying to read the disk too fast. Also, I am getting this text sometimes:

dd: reading `/dev/sdb': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 8.9529 s, 0.0 kB/s

Usually it then says that /dev/sdb doesn't exist. After a few seconds, I try again and it will find the file. I usually get the least errors after connecting the device. Any ideas?

Also, an interesting development. My zip drive has a light on it that flashes when it is being read or written. The first one or two times I try to copy the data, it flashes like it should. However, after a few times, it stops flashing when I try to read the data. It even happens when dd actually gets data.

There can be various factors that affect a drive access light. Some lights are very fast, reading a single block might almost not make a visible flash at all. While other lights are fairly slow, a single block read can cause the light to be on for quite some time.

Also, Linux tends to make fairly good use of memory. For example, depending on the situation, reading a single block over and over again, might only physically access the device the first time the block is read, but on subsequent reads, the system might just be able to get the block from system memory buffers.

If you haven't already, you might want to check your system messages files to see what the system thinks is happening with the device. On the Linux I'm using, that file is /var/log/messages. It may be elsewhere on other distros.