Before endeavoring to help I must tell you that I am not a programmer by any stretch. I'm using linux, kernel version 2.6.18.8. I'm working from the link below to arrive where I'm at so far:
http://linux.derkeiler.com/Newsgroup...4-03/0561.html

First of all, I am working with a gzipped tar file. I suspect that fixing the gz file will still leave me with a corrupt tar file. Please do not hesitate to let me know if reconstructing/recovering the tar file is futile. I am also using khexedit, which I suspect I will need to fix the .gz and tar file within it.

I've downloaded gzip version 1.3.12, edited unzip.c to include
The package compiled perfectly.

I ran: (It's a big file, 3.2GB)

This gave me
The questions I have are figuring out disk block size and how to concatenate a valid .gz header.

This is the layout of the hard drive where the tar.gz file was backed-up to:
Units = cylinders of 16065 * 512 = 8225280 bytes

The drive layout is probably not terribly relevent with the exception of figuring out where I am in the file on disc.

I've also read algorithm.doc that is included with the sources but it's beyond my ability to grasp. Also, would anyone be able to paste a commented header example that I can look at?

Please do not hesitate to let me know if there is more information I can provide.

Thanks,
Andrew

Well, I'm not a progammer by any stretch of the imagination either, but this is how I would approach this problem:

Make a new file called example.txt -doesn't matter what's in it. Just fire up khexedit and type something and save it. Then gzip it to create example.gz. Then open up example.gz and look for the text title example.txt. Copy the block up to the text "example.txt" and save it as header.gz. I've almost certainly missed something entirely because of the bit shifting the howto talks about. You might have to try a few times to get a valid header.

To concatenate this to your damaged piece of damaged.gz use

cat header.gz damagedpiece.gz > newfile.gz

To get the damagedpiece.gz file you'll have to take the damaged.gz file and remove the first 469237760 bytes from it using khexedit; that will leave however much of it you haven't extracted yet. I presume the rounding to the nearest compression blocks means that you'll have to round to the nearest 8*64K bits.

Hopefully, half competent help is no worse than no help at all.

Thanks mostlyharmless. Indeed, I've built a career on half-competent help. So, thank you for helping me think this through. Creating a mostly empty tar.gz file is a really good idea. Hadn't gotten enough clarity to think about that in my frothing, "omg, my home directory is toast" quest for answers. :-)

As a future note to myself: Never backup to a nfs share again, and in the future add the -W switch to verify the archive...

Oh boy. I'll give your suggestion a whirl and post the result.

Thanks again,

Andrew

Suggest reading this:
http://www.gzip.org/recover.txt

Hi ya H_TeXMeX_H,

Thanks for the file. That's the same information that's referenced at the link in my original post. I've gotten to the part of the gzip source compile and retrieving the information before the defect in the file. The part that's still got me is concatenating a new header on the the damaged file beyond the defective part. One of the obstacles I'm running in to is the shear size of the file. khexedit just chokes because it wants to load the entire file in the memory before working on it, and it's been a really long time since I used to edit files directly on disc back in DOS 3.3 and 5.0 (anyone remember x-tree?). So for now, I grabbed a backup from a month or so ago and am trudging on. I haven't given up, I'm just temporarily stuck.

I'll post more when I have more info.

Thanks,

Andrew

Oh, hehe, sorry I didn't notice, it looked different to me.

Try using regular hexedit, I've never noticed any slowdown when opening large files with it, it opens them instantly.

Hehehe, no worries. :-)

Awesome. Installing now. Thank you for the tip! I'll let you know how it goes.

Andrew