chris chryed, > On Sat, Sep 16, 2000 at 02:14:56PM -0400, [EMAIL PROTECTED] wrote:
> > yikes, I can do without the gory details :) does this mean that once I > > find a block of a tar, I can start extracting, even if it wasn't the > > middle? > You want to find the first block of the tar. If you will indulge a bit > of ASCII art, a tar looks like this: > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | H | F | F | H | F | F | F | H | F | F | F | F | H | F | H | F | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > where H is a header and F is the file's data. Each block as I said is > 512 bytes. The header contains information like how many bytes come in > the file data. If you miss the first header you miss the first file. As usual, there's only one important file (my unfiled tax return :) Even if I miss most of them, I"m ok (though I"d really like to get them all back, of course . . .) > > Or should I just start using "dd if=/dev/hda7 skip=1| tar -tvf -" and > > incrementing the skip until I hit something (I think these two files > > would be the only ones ever to be created on that partition). > This could work if you had a recently defragmented partition or a very > small tar file. In any other case, I'm going to guess that you're SOL > and going to give up. I tried to recover data from a screwed up FAT > partition once and ended up running mke2fs on it after a day. The > problem with dd on a normal filesystem is that a file can have multiple > other files in between its start and finish. I believe that these are the only two files ever written to the disk, and I am certain that there has been nothing written after it. So I'm assuming that they're contiguous . . . > > thanks > I hope it helps, me too :) thanks, I'll try again tomorrow night . . . --