What does a bad block look like in a tar file ... does it default to some junk, or are the surrounding blocks concatenated together, ignoring the holes, and screwing up the metadata?

Backstory:

I have a dual-boot laptop that began to exhibit a failing harddrive. winXP would no longer boot. Linux was able to come up, but only after fsck-ing bad blocks in some linux partitions.

After mounting the winXP partition, I created, in a linux partition, a 2GB tar file containing the winXP Thunderbird email client Inbox, and then ftp'd that over to another winXP machine.

This succeeded, sortof:

1) On the winXP destination drive, Thunderbird was able to open the ftp'd, untarred Inbox, and I had access to all the emails that I attempted to open.

2) a first attempt to ftp the file to another linux box ended in a hung transfer, uninterruptible sleep, and the consequent demise of the linux destination drive.

3) StorageCraft baremetal backup for the winXP destination drive, containing the transferred Inbox file, churns for hours with CRC errors.

4) Now, immediately following a Thunderbird update on the winXP destination drive, Thunderbird
fails to run.

So those bad sectors on the source drive appear to be problematically represented on the destination drive. I need to fix that.

I'm considering going back to the source drive, fsck-ing the winXP partition, and starting over. However, I'd sincerely like to avoid more any more uninterruptible i/o, so i hesitate to do this.

I'd mostly like to understand what the problem tar file looks like at the bit or block level.

Thanks!
Paul

PS: GNU Tar 1.13.25

It's not obvious to me what you were doing, even after reading your
post three times. To answer your first question about tar, it will
exit immediately with an error when it tries to read or write a bad
block.

At one point you say you have a good backup of the 2GB file. If so,
hang onto it until you buy a new hard drive. You might not be lucky
enough to get another backup.

Today's hard drives are built to survive a few block level errors
and you won't even know that they happened. However if you're seeing
errors, that means you've already had more than the normal number
of bad blocks. The hard drive will not improve, not matter how many
times you run disk checking software.

My advice is to try to back up whatever you can to another hard
drive and then replace the one that's going bad.

hey thanks for your reply. sorry if the sequence was unclear, it went like this:

1) hard drive clearly exhibits bad sectors: laptop cannot boot into winXP, linux fsck identifies others.
2) laptop boots to linux, linux mounts winXP partition.
3) 2GB or so of the winXP partition is tarred over to a linux partition (winXP partition is mounted RO).
4) that tarball seems to be problematic, and i'm guessing that's because there were bad blocks in the winXP target 2GB.

You claim that can't be, and if so, then i have no explanation for the troubles that followed (items 2,3,4 in the original post. The time sequence for that list was 2-1-3-4).

I have a baremetal backup for the winXP partition, but it predates the hard drive failure by about two weeks. It's those last two weeks of email I was after. Thunderbird, the email client that created the files on the bad drive, was initially able to work with the untarred tarball on a different winXP host, after successfully integrating them into the application. But after a T-bird application update, T-bird now chokes to the point of non-runnability.

I had used the installed linux fsck on the bad drive to map around bad sectors in the linux partition. So I was considering using a linux boot disk like knoppix to do the same for the winXP partition, and then get perhaps a clean tarball after that.

But if as you say tar cannot complete given bad blocks, then there can't be any within the 2GB ... end of story.

Anyway, thanks again. I'm in no rush to replace the bad drive on that old laptop, so I may continue to screw around with it.

Okay, it sounds like all the files have been written to the same
hard drive. Not good. It's possible that the 2GB file is good,
but you're getting errors when trying to read from it.

My suggestion would be to get a knoppix disk and make another
backup of all your important files in Windows and in Linux
to another drive--either on a network or USB attached. The
advantage of using knoppix is that the OS is not stored on
the hard drive that is failing and the partitions will be
mounted read-only. Once you make the backup, get a new drive
to replace this one. This drive is already bad and it will
just continue to get worse.

> It's possible that the 2GB file is good,
> but you're getting errors when trying to read from it.

That's what i'm talking about. It's good according to some metrics, but it fails spectacularly in other cases.

Yes, so let me repeat for one last time...don't use files on this
hard drive! It's going bad. Make one final backup using a knoppix
disk onto another drive, test that the backup is good and then
destroy the bad disk.

right, yes, except you want knoppix to read the bad the drive, and then write something useful from that. me too, but just 2GB. no sweat except there's a good chance that there is corruption at the hardware level, and so how is that handled? if either read or write process aborts, then it can't be handled, and that's a well-understood result. otherwise, hard to tell what you get, unless you're familiar with how the processes work.

Have you tried to rsync the data to another device?

rsync -av /data /good/drive/

rsync checks the data so you won't have corrupt files,
or rsync won't copy the corrupt data

i have not, but it sounds almost perfect, so thanks for that! the 'almost' part comes from googling "rsync hangs".

apparently there is/was a known problem with cygwin, and then some mysteries.

i have a pair of large external hard drive "mirrors", one of which i have killed twice with uninterruptible sleep i/o. then i sit on pins and needles until it's replaced and repopulated. i suppose the thing to do is populate a replacement drive first, then rysnc after that.

kinda like calling 911 and putting them on hold before throwing the switch.

just for the record, the other expensive (replace-destination-drive) file transfer was a copy from a ten year old CD-R. won't do that again. the good news is that each time i replaced the drive the price went down.

ps: the drive is WD Caviar SATA, and WD makes a microsoft only repair utility, but i have no windows SATA hosts, so the dead ones go in a box.

Turns out that the way to go is the GNU ddrescue on a Ubuntu Rescue Remix live CD system.

get it here:
http://ubuntu-rescue-remix.org/

read about it here:
https://help.ubuntu.com/community/DataRecovery